# Laravel Folio: file-based routing for Laravel applications > Laravel Folio is the official page based router for Laravel, packaged as a separate composer dependency that sits alongside the framework rather than inside it. The repository is deliberately small, with a functions.php entry point, a src/ directory, stubs and resources for publishing, and a workbench harness for testing, and the README itself is thin because the documentation lives on laravel.com. **laravel/folio** — Page based routing for Laravel. - Repository: https://github.com/laravel/folio - Stars: 608 · Forks: 53 - Language: PHP - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/laravel-folio ## A router as an optional package, not a framework feature The repository description is a single phrase: page based routing for Laravel. The README expands it slightly, calling Folio a page based router designed to simplify routing in Laravel applications, and then points the reader at the official documentation on the Laravel website. The packaging is the part worth understanding before anything else. Folio is not a branch of the framework and it is not a fork of the router. It is a separate composer package that an application adds, sitting next to the framework rather than inside it, and the repository layout reflects that separation. The top level holds a src/ directory for the implementation, a resources/ directory, a stubs/ directory, a functions.php file at the root, and a workbench/ directory. That functions.php file at the root is a hint about how Folio is meant to be used. A single PHP file that an application includes is a familiar pattern from a framework era before service providers, and a router that is bootstrapped by including one file fits that shape: you add the dependency, include the file, and Folio's routes become available to the application. The alternative reading is that Folio registers itself as a service provider and functions.php is a convenience entry point for manual bootstrapping, which is a common pattern in the Laravel ecosystem for packages that need to be configured before the application boots. The repository does not say which of the two it is, and that is one of several places where the README defers to the documentation site rather than answering a question itself. The licence is MIT, the primary language is PHP, the default branch is master, and the last push was on 2026-10-14 with the project not archived. The recent releases are v1.2.0 from 2026-08-18, v1.1.21 from 2026-08-11 and v1.1.20 from 2026-08-05, so this is a project in active maintenance with a steady patch cadence inside a 1.x line. ## What the repository contains, and what it deliberately does not The top-level listing is short, and each entry tells you something about the design. There is a CHANGELOG.md, which for a 1.x package means the change history is expected to be consulted between releases. There is a phpstan.neon.dist for static analysis configuration and a phpunit.xml.dist for the test runner, both in the dotfile-plus-dist naming convention that keeps a project's own configuration out of the way of consumers. There is a .editorconfig and a .gitattributes, the two files every repository in the Laravel ecosystem has because the framework's own tooling expects them. The stubs/ directory is the interesting one. A stubs directory in a Laravel package holds the files that get published into the consuming application, and the conventional use for a router is a directory of view templates or a set of route definition files that the application can edit without the package overwriting them on the next update. The presence of stubs alongside resources/ tells you Folio is designed to put files into the application and let the application own them afterwards. Then there is workbench/ and testbench.yaml. A workbench is the standard way to build and exercise a Laravel package against a real application rather than in isolation, and the testbench.yaml file is its configuration. The pairing tells you the project expects changes to Folio to be tested inside a running Laravel application, not just through unit tests, and it is the clearest signal in the repository about how a contributor is expected to work. What the repository does not contain is any documentation beyond the README. There is no docs/ directory, no guide to the routing conventions, no description of the configuration options and no examples. That absence is deliberate and consistent with the repository's purpose: it is a distribution point for a package whose user-facing documentation is the Laravel website, and the README's documentation section is a single link to it. ## Why a page based router exists in a framework that already has a router The obvious question about a router packaged for a framework that already routes is why it exists at all, and the README does not answer it, so it is worth being careful about what can be said from what the repository shows. What the repository shows is that Folio is a first-party package. It lives under the laravel organisation, it is on Packagist, it has a GitHub Actions test workflow badge, and it is released with semantic version tags. The CHANGELOG.md, the phpstan configuration, the phpunit configuration and the workbench harness together describe a package held to the same standards as the framework itself, which is a different status from a community routing package that happens to be compatible. The structural answer is in the name. A page based router derives the route from the location of a file rather than from a list of registered routes, which suits applications whose content is naturally a set of pages, and suits teams whose mental model of their site is a directory. A framework router that requires every URL to be declared in one place does not fit that model as well, and a separate package lets the two coexist in the same application without either one dictating. The coexistence point matters for evaluation. Folio is described as designed to simplify routing in Laravel applications, not as a replacement for the framework's routing, and the fact that it is a dependency you add rather than a setting you flip is the practical expression of that. An application that wants a small content section driven by files can have that while keeping explicit routes for everything else, and an application that wants the whole site driven by files can go further. The repository gives you no example of either, which is why the documentation link matters. The other thing the repository shows is that this is a maintained surface rather than an experiment. The v1.1.20, v1.1.21 and v1.2.0 tags in under two months, and a v1.2.0 minor bump, are the shape of a package that is being extended rather than rewritten. ## What a contributor would actually work with The contribution guide is not in this repository. The README says the contribution guide can be found in the Laravel documentation, and points at the code of conduct and the security policy on GitHub for the vulnerability reporting route. All three are standard for the ecosystem, and it confirms that Folio is administered as part of Laravel rather than as an independent project with its own process. The practical consequence is that a contributor to Folio is contributing to Laravel as a whole, with the review expectations that implies, and the security reporting route is the repository's own GitHub security policy rather than a separate address. For local work, the repository gives you a standard Laravel package layout and a testbench.yaml pointing at a workbench directory. A workbench in the Laravel ecosystem is a small application used to develop and test the package in context, which is the pattern the maintainers of packages in this family use so that a change can be exercised through a real HTTP request rather than a unit test with a mocked container. The presence of .github/ at the top level indicates where the automation lives, and the test workflow badge at the top of the README is the build status for the package's test suite. A contributor would therefore work in an IDE or editor with the workbench as the harness, run phpunit against it, and submit through the same review process as any other Laravel package. The one thing a contributor will not find locally is the routing documentation, which means the conventions Folio expects, the naming rules it applies, and how it interacts with the framework's own router all have to come from the Laravel site. That is a real friction point for anyone evaluating the project in isolation, and it is the main thing to know before reading the source. ## How to evaluate it, and what to read first An evaluation of Folio has three parts, and only one of them can be done from this repository. The first is scope. Folio is a router for pages, so the question is whether your application's URL space is page-shaped. A site whose URLs are mostly documents, articles, listings and their sub-pages is a good fit. An application whose URLs are API endpoints, webhooks and a handful of stateful actions is not, and Folio would be a small part of the routing at best. The second is coexistence. Because Folio is a package you add, you need to know how it interacts with the routes your application already declares, and what happens when a file and an explicit route would match the same URL. None of that is in this repository. The Folio documentation on the Laravel site is the place to find out, and it is worth reading before installing anything, because the answer decides whether Folio is a feature or a conflict. The third is the operational picture, and here the repository does help. The release history shows a maintained 1.x line with a recent v1.2.0, the MIT licence removes any licensing question, and the project sits inside the Laravel ecosystem with the CI, static analysis and test infrastructure that implies. There is no separate homepage for Folio, which is consistent with it being documented inside the framework's own documentation set. The reasonable first step for a team considering Folio is to read the documentation, install the package in a branch, and route a small section of an existing application through it, rather than trying to reconstruct the conventions from the source. The source is short, but the conventions live in the docs, and Folio is the kind of package where the conventions are the product. One last thing to keep in perspective. The README for this project is three sentences of description, and everything else is a link. That is not a sign of a thin project, since the release history and the test infrastructure say otherwise, but it does mean that this repository cannot tell you how Folio behaves, only that it exists and is maintained. ## Conclusion Adopt Laravel Folio if you want your Laravel application to route by file layout the way a static site or a content site does, and if you are happy to hand route definition over to the filesystem for the parts of the application that suit it. Do not adopt it expecting Folio to replace the framework's own router wholesale, because Folio is a separate optional package that layers page based routing onto an existing Laravel application rather than a replacement for the framework core. Before you commit, read the Folio documentation on the Laravel site, since the repository README does not describe the routing conventions, the configuration or the middleware behaviour, and check how the workbench harness in the repository works, because that is the part of the project that shows how the maintainers expect a change to Folio to be tested. ## FAQ ### What is Laravel Folio? It is a page based router for Laravel applications, shipped as a separate MIT licensed composer package that an application adds alongside the framework. The README describes it as designed to simplify routing in Laravel applications, and points to the Laravel website for the full documentation. ### How is Folio different from Laravel's built-in routing? The repository does not document the difference, and the README only says Folio is a page based router designed to simplify routing. What the packaging shows is that Folio is an optional dependency rather than a framework setting, so it layers page based routing onto an application that can also declare explicit routes. ### What does the Folio repository actually contain? A src/ directory, resources/, stubs/, a functions.php file at the root, a workbench/ directory with a testbench.yaml harness, a CHANGELOG.md, phpstan.neon.dist and phpunit.xml.dist, plus the usual .editorconfig and .gitattributes. There is no docs/ directory, because the documentation is hosted on the Laravel website. ### How actively is Laravel Folio maintained? The recent releases are v1.2.0 from 2026-08-18, v1.1.21 from 2026-08-11 and v1.1.20 from 2026-08-05, and the last push to the repository was on 2026-10-14. The project is not archived and sits under the laravel organisation with a CI test workflow. ### How do I report a security issue in Laravel Folio? The README points at the repository's own GitHub security policy, and says to review it for how to report security vulnerabilities. Contribution and code of conduct guidance are hosted in the Laravel documentation rather than in this repository. ## Sources - [Issues](https://github.com/laravel/folio/issues) - [laravel/folio on GitHub](https://github.com/laravel/folio) - [License: MIT](https://github.com/laravel/folio/blob/master/LICENSE) - [README](https://github.com/laravel/folio/blob/master/README.md) - [Releases](https://github.com/laravel/folio/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/laravel-folio