In Laravel 13, can routes defined with closures be cached by php artisan route:cache, and what can still make route caching fail?

## The question behind the question For years a common piece of Laravel advice was: "do not use closures in your route files, because `route:cache` cannot serialize them." Interviewers still ask it to see whether a candidate's knowledge is current. In Laravel 13 the answer is that **closure routes can be cached**. ## How route caching works `php artisan route:cache` (`RouteCacheCommand`) does four things: 1. calls `route:clear` to remove any old cache file; 2. boots a fresh copy of the application and collects every registered route; 3. calls `prepareForSerialization()` on each `Illuminate\Routing\Route`; 4. writes the compiled collection to `bootstrap/cache/routes-v7.php`. On later requests the routing provider sees that `routesAreCached()` is true, calls `loadCachedRoutes()`, and never executes the route files. ## What happens to a closure `Route::prepareForSerialization()` in Laravel 13 contains this logic: - if `$this->action['uses']` is a `Closure`, replace it with `serialize(SerializableClosure::unsigned($closure))`; - if the route has a `missing` closure (the callback run when implicit model binding finds nothing), wrap it the same way; - compile the route and drop the router and container references. `SerializableClosure` comes from the `laravel/serializable-closure` package. It captures the closure's source code, its bound variables and its scope so the closure can be rebuilt later. The **unsigned** variant does not sign the payload with a secret key; that is acceptable because the payload is a file the application wrote itself. Laravel 13 requires `laravel/serializable-closure` `^2.0.10`; support for v1 was removed in 13.0. ```php <?php use Illuminate\Support\Facades\Route; // Cached fine in Laravel 13 Route::get('/', fn () => view('welcome')); $region = 'north'; Route::get('/rota', fn () => view('rota', ['region' => $region])); ``` ## What can still go wrong Closure support does not mean every route file caches cleanly: - **Unserializable captured values.** Whatever the closure captures with `use` (or through arrow-function auto-capture) is serialized with it. An object that refuses serialization, such as a `PDO` connection, makes `route:cache` throw instead of writing the file. - **Captured objects at request time.** `Route::runCallable()` calls `unserialize()` with an `allowed_classes` list that names only the serializable-closure classes. A captured instance of any other class, such as an application value object, therefore comes back as `__PHP_Incomplete_Class` and fails when the closure uses it. Scalars and arrays are unaffected. - **Logic that only ran while the file executed.** With a route cache, `routes/web.php` does not run at request time. Any side effect placed in a route file, such as registering a binding or reading a request value to decide which routes exist, is frozen at cache time or skipped. - **Conditional routes.** A route file that registers routes only in some environments is evaluated once, when the cache is built, in the environment of that build. - **Duplicate route names.** Two routes with the same name make `route:cache` fail during serialization; that route-naming rule is covered with route names themselves. ## How a cached closure runs The cached route file stores the action as a serialized string. On a request that matches the route, `Route::runCallable()` checks whether the action is a serialized closure, unserializes it with the restricted class list, calls `getClosure()` on the result and invokes it with the resolved parameters. Two consequences follow: - the closure's **code** is whatever it was when `route:cache` ran, so editing the route file changes nothing until the cache is rebuilt; - the closure's **captured values** are rebuilt from the cache file on each request, so they behave like constants baked into the release. The restricted `allowed_classes` list is a hardening choice: even though the file is written by the application, unserializing arbitrary classes from it is avoided. ## Closures or controllers? | Concern | Closure route | Controller route | |---|---|---| | Route caching in Laravel 13 | works | works | | Captured variables | serialized into the cache file | none | | Readability in `route:list` | shows `Closure` | shows `Controller@method` | | Testing and reuse | logic lives in the route file | logic lives in a class | The honest answer in an interview: caching is no longer a reason to avoid closures, but controllers keep route files short, show up clearly in tooling, and keep business logic in testable classes. Small `Route::get('/', fn () => view('welcome'))` style routes are fine to keep. ## Version note The behaviour described here is Laravel 13 (framework 13.34). Older releases rejected closure routes during `route:cache`, which is where the outdated advice comes from; if you maintain a very old application, check its version before relying on cached closures.