laravel/framework: the core package, not the app skeleton

Two repositories, and this is the one without an application

The first thing the README says is a note, not a feature list: this repository contains the core code of the Laravel framework, and anyone who wants to build an application should visit the main Laravel repository instead. That single sentence resolves most of the confusion around the project. There is a framework package and there is an application skeleton, and they are separate. The skeleton is what you clone or generate when you start a project, complete with configuration, a public directory and a front controller. The package is what that skeleton then depends on through Composer.

So who is this repository for? People maintaining or extending the framework itself, contributors working against the contribution guide, and teams whose build pipeline pulls the package directly rather than through a starter project. If you fall into the last group, you are taking responsibility for wiring up the pieces the skeleton would otherwise give you: bootstrap files, service providers, configuration, and the entry point that receives HTTP requests. That is a real amount of work, and it is the reason the README points newcomers away rather than toward itself.

What the framework actually provides

The README lists the pieces in plain terms. A routing engine handles incoming requests. A dependency injection container resolves class dependencies. Session and cache storage each support multiple back ends. Schema migrations are database agnostic. Background job processing runs through queues. Event broadcasting pushes updates in real time.

Read that list as a set of boundaries rather than a feature sheet. The container is what makes the rest composable: a route closure, a controller, a queued job and a broadcast event all get their dependencies resolved the same way, which is why the framework can offer so many subsystems without them turning into a pile of global helpers. The multiple session and cache back ends matter more than they sound. They mean the same application code can run against a file-based cache in development and a different store in production, with the switch living in configuration rather than in your classes.

Database-agnostic migrations are the claim worth scrutinising. The framework provides the migration layer and the schema builder, but the connection itself depends on a PHP database extension and a driver. The repository's own docker-compose.yml is the clearest evidence of how many back ends the test suite exercises: it defines services for DynamoDB, Memcached, MySQL and Redis, with Postgres, MariaDB, MSSQL, and a three-node Redis cluster present but commented out. That file is for running the framework's tests, not for your application, but it tells you which stores the project treats as first-class.

Installing laravel/framework with Composer

The framework is distributed as a Composer package. The README links to its Packagist page, and the package name is laravel/framework. If you are building an application, the README's own instruction is to start from the laravel/laravel repository, which brings the package in as a dependency along with a working directory structure. Adding the package on its own gives you the library and nothing else.

A minimal require looks like this. Run it in the directory that holds your composer.json.

composer require laravel/framework

After it completes you should see the package listed in your composer.json require block and a vendor directory containing the framework source. Nothing will respond to HTTP yet, because there is no front controller, no bootstrap and no configuration. If you want a running application rather than a library, use the starter repository instead and let it pull this package in.

The repository also ships a docker-compose.yml for its own test suite. It is not an application runtime, but it shows the ports the tests expect: MySQL on 3306, Redis on 6379, Memcached on 11211, and DynamoDB Local on 8000. If you plan to run the framework's tests against a real store rather than a fake, those are the defaults to match.

docker compose up -d mysql redis memcached

That starts the three services the file defines without comment. The other database services are present but commented out, so enabling Postgres or MariaDB means editing the file first.

Where the framework stops helping

The README is honest about scope but silent on operations, and that gap is where adoption goes wrong. Queues are listed as a capability, yet running them in production means a long-lived worker process under a supervisor, plus a restart on every deploy so the workers pick up new code. Nothing in the README describes that. The same applies to the scheduler and to broadcasting, which needs a separate server or service to fan events out to clients. The framework provides the client side of these systems; the process management is yours.

There is a second limitation in the repository layout itself. Top-level entries include phpstan.src.neon.dist, phpstan.types.neon.dist, pint.json, rector.php, phpunit.xml.dist and a types directory. Those are the framework's own static analysis, formatting and test configuration. They are not templates for your application, and copying them will not give you a working quality setup. The config/ and config-stubs/ directories are similarly internal to the project.

Finally, this is the wrong repository to open an issue against for application-level problems. The README directs contributors to a contribution guide and security reports to a separate policy file. A question about your routing configuration belongs in the application repository or the support channels, not here.

How it compares with Symfony and CodeIgniter

The most direct comparison is Symfony. Both are PHP frameworks, both are MIT-licensed, and both are built around a dependency injection container. The difference in approach is packaging. Symfony publishes its components as separate installable packages, so a project can take the router, the console and the mailer without adopting the rest. Laravel ships as one framework package with the subsystems listed in the README already inside it, which shortens setup but means upgrades move the whole set together.

CodeIgniter sits at the other end. It carries a smaller default footprint and a lighter configuration story, which suits small applications where the queue, broadcast and container machinery would go unused. Choosing Laravel means accepting those subsystems as part of the install even if you never queue a job. For a project that will grow into background processing and real-time updates, that is a reasonable trade. For a small internal tool, it is weight you carry for nothing.

A plain PHP application with a router library is the third option, and it is genuinely the right answer when the request handling is trivial. The framework's value shows up when you need several of the listed capabilities at once and want them to share the same container.

Maintenance, releases and the MIT licence

The repository is not archived. The most recent push recorded is 2026-08-25, and the releases on that date include v13.29.0 and v13.27.0 on the 13.x line alongside v12.68.0 on 12.x. Two maintained lines receiving releases on the same day is the practical detail here: teams on the previous major version are still getting updates, so an upgrade is a planned project rather than an emergency.

The default branch is 13.x, which means the framework's development targets that line. RELEASE.md sits at the top level and is the file to read before you plan an upgrade, since it is where the project documents its release process. The README does not describe rollback or downgrade steps, so treat version pinning in composer.json as your own responsibility.

The licence is MIT, stated in the README and in LICENSE.md. That permits commercial and closed-source use, and it means the framework carries no copyleft obligation on your application code. It also means no warranty. For anything with a compliance process, the licence file is short enough to read in full, and it is the authoritative text rather than the README's one-line summary. None of this is legal advice; route it past whoever handles licensing if your organisation requires that.

Editorial conclusion

Adopt laravel/framework if you are building or maintaining a PHP web application and want routing, a dependency injection container, migrations, queues and broadcasting in one MIT-licensed package. Do not start here if you have never built a Laravel app: the README tells you to go to the laravel/laravel repository instead, and that is the right first step. Before committing, verify the PHP and extension requirements for the release you pick, check whether your host can run the queue worker and scheduler as long-lived processes, and confirm the database driver you need is one of the back ends the documentation lists.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes