# laravel/framework holds the core code, and 12.x is still taking patches

> laravel/framework is the PHP core of the Laravel web application framework, licensed MIT, with 13.x as its default branch. It is the wrong repository to start a project from and the right one to read when you need to know what a framework component does, and the two facts that shape day to day work are that 12.x still receives patch releases and that the contributor rules are hosted on a documentation site rather than in the tree.

**laravel/framework** — Laravel is a web application framework with expressive, elegant syntax.

- Repository: https://github.com/laravel/framework
- Website: https://laravel.com
- Stars: 34,941 · Forks: 12,007
- Language: PHP
- License: MIT
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/laravel-framework

## This repository is the framework, not the application skeleton

The first thing the page says is a boundary. This repository contains the core code of the Laravel framework, and anyone who wants to build an application using Laravel is pointed to the main Laravel repository instead. The distinction is easy to miss and expensive to get wrong. If you start a project from this repository you get the framework classes and none of the surrounding application: no bootstrap wiring, no directory skeleton, no front end build. The header links to the framework's package page on Packagist, which is the route for consuming it as a dependency, and that is the correct path for an application. This tree is the layer you read when a routing, container, session, cache, migration, queue or broadcasting behaviour does not match what the documentation says, and it is the layer you patch when you fix one.

## Two major lines shipped releases on the same day

The default branch is 13.x, and the release history shows the 12.x line still being worked on alongside it. v13.34.0 and v12.69.3 were both published on 2026-09-29, and v13.33.0 on 2026-09-22, with the last push to the default branch also on 2026-09-29. So the newest tag is not the whole picture, and one major line is not a dead branch waiting to be deleted. The practical consequence is that a version choice has to be made on purpose. An application that follows the newest tag moves onto the newer major line without a migration step being chosen, and an application that needs a fix already available in 12.x may be missing fixes in 13.x, or the reverse. RELEASE.md sits in the root of the repository and describes how releases are produced, but the README does not link to it, so the versioning policy is available in the tree and invisible from the landing page.

## Contribution and security rules are hosted on laravel.com, not in the tree

Three things a contributor normally expects to find as files are all links here. The contribution guide is said to live in the Laravel documentation, the code of conduct is at the code of conduct anchor within that same contributions page, and security vulnerabilities are handled through the security policy on GitHub. Look at the root and there is no CONTRIBUTING.md and no SECURITY.md. The entries are .editorconfig, .gitattributes, .github, .gitignore, .styleci.yml, CHANGELOG.md, LICENSE.md, README.md, RELEASE.md, bin, composer.json, config-stubs, config, docker-compose.yml, a pair of PHPStan configurations, phpunit.xml.dist, pint.json, rector.php, src, tests and types. Two consequences follow. You cannot read the rules at the revision you checked out, and the rules you must follow can change on a documentation site independently of the branch you are working on, which is worth knowing before a review turns on a requirement you never saw.

## The test stack defaults to MySQL 5.7 with a passwordless root

The compose file at the root is the bring-up for running the test suite against real services, and the default posture is worth reading before you run it. Four services are active. DynamoDB local on port 8000, memcached on 11211, redis on 7.0-alpine on 6379, and MySQL, configured like this:

```yaml
  mysql:
    image: mysql/mysql-server:5.7
    environment:
      MYSQL_ALLOW_EMPTY_PASSWORD: 1
      MYSQL_ROOT_PASSWORD: ""
      MYSQL_DATABASE: "forge"
      MYSQL_ROOT_HOST: "%"
    ports:
      - "3306:3306"
    restart: always
```

An empty root password combined with a root host of percent sign is a development posture, and the port is published to the host rather than kept internal, so this is a compose file to run on a workstation and not a template to copy to a shared runner or a machine others reach. It also sets the default test database to MySQL 5.7, which is the only database that is actually running when the file is used as shipped.

## Postgres, MariaDB, MSSQL and Redis cluster are all commented out

Everything else in the compose file is present but disabled. Postgres 15, MariaDB 11, and an mssql 2019-latest block each sit behind comment markers with their own environment and port settings, and there are three redis cluster nodes, redis-cluster-0 through redis-cluster-2, on ports 7000, 7001 and 7002, each started with redis-server --port 7000 --appendonly yes --cluster-enabled yes and its port substituted in turn. The framework advertises database agnostic schema migrations and multiple back ends for session and cache storage, and this file is where the gap shows. A default bring-up exercises MySQL, plain Redis and memcached only, so behaviour specific to Postgres, MariaDB, SQL Server, or a clustered Redis with appendonly enabled is not covered until a contributor uncomments a block and edits ports. Cross-database confidence is therefore something you arrange, not something you inherit from a fresh checkout.

## Two PHPStan configurations, a formatter, a refactoring tool and a hosted style service

The repository carries its own quality toolchain, and it is wide. Static analysis is configured twice, in phpstan.src.neon.dist and phpstan.types.neon.dist, splitting the src tree from the types tree. Formatting is configured in pint.json and again in .styleci.yml, which is a hosted service rather than a local file, and rector.php configures automated refactoring. Tests run under phpunit.xml.dist. The .dist suffix on the PHPStan files and on phpunit.xml.dist marks them as committed defaults that a machine is expected to override locally, so a contributor generating local configuration gets a separate file rather than editing the tracked one. What the page does not say is which of these gates a pull request and which is advisory, and with five separate quality tools configured, that question is the first thing a new contributor has to answer before a change is accepted.

## The feature list names six subsystems and explains none of them

The page enumerates what the framework covers: a routing engine, a dependency injection container, multiple back ends for session and cache storage, database agnostic schema migrations, background job processing, and real-time event broadcasting. Each name is a link into the documentation. None is described here, and no configuration file, environment variable or default is given, so the page cannot tell you which cache driver is selected by default or what a queue connection requires. The repository does contain a config directory and a config-stubs directory, which is where those answers actually live, but the landing page does not walk you to either. Learning therefore happens through laravel.com/docs, through the Laravel Learn material, and through the Laracasts video library. Read the tree when the documentation is not specific enough, and expect the page itself to remain a directory of links rather than a reference.

## Conclusion

Clone it when you are working on the framework itself, reading a component end to end, or tracking what changed between lines. Do not clone it to start an application, because the skeleton lives in a different repository and nothing here produces a runnable project. Before you pin a version, decide deliberately between the 12.x and 13.x lines rather than following the newest tag, and before you open a pull request, read the contribution guide and the security policy on laravel.com, since neither file exists in the root of this repository.

## FAQ

### how to install framework

The page carries no install command. Its header links to the framework's package page on Packagist, and its note says that anyone who wants to build an application using Laravel should visit the main Laravel repository, which holds the application skeleton rather than the core code.

### how to use framework in web development

Laravel is a PHP web application framework whose stated components are a routing engine, a dependency injection container, multiple back ends for session and cache storage, database agnostic schema migrations, background job processing, and real-time event broadcasting. Each is documented at laravel.com/docs rather than in the repository.

### how to use framework in programming

This repository is the core code of the framework, written in PHP and licensed under the MIT license, and it is the layer to read or patch when framework behaviour does not match expectations. The default branch is 13.x, and the license is stated in LICENSE.md at the root.

### how to use framework

The page routes learning to laravel.com/docs, to the Laravel Learn material for guided projects, and to the Laracasts video library. It contains no tutorial of its own, so the repository is not where you start, and the config and config-stubs directories are where the framework's own defaults are kept.

## Sources

- [Official documentation](https://laravel.com)
- [Official README](https://github.com/laravel/framework#readme)
- [Project repository](https://github.com/laravel/framework)
- [Release notes](https://github.com/laravel/framework/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/laravel-framework