league/container: a small PSR-11 container with a recent PHP floor

A container defined by its interfaces, not its features

The League container is described as a small dependency injection container, and the interesting part of that description is the compliance statement that follows it. The package is compliant with PER-CS, PSR-4 and PSR-11, and the README goes further than most projects do on this point by inviting patches when you notice compliance oversights. Those three standards cover different layers. PSR-11 is the container interface itself, the contract that says how you get an entry, ask whether one exists and tell the container to delegate. PSR-4 is the autoloading convention, so the package sits in a Composer project without a custom autoloader. PER-CS is the coding style standard, which matters less at runtime and more when a team has one house style across several League packages. The practical consequence of the PSR-11 part is portability, because a class that type hints against the PSR-11 interface can be handed any compliant container, including one built into a framework, and that is a different proposition from a container that is only usable through the framework that ships it.

The 6.x branch and a PHP 8.3 floor

The default branch is 6.x, and the requirements section is the first thing to read, because it has moved. This version supports PHP 8.3, PHP 8.4 and PHP 8.5, so there is no version of the current line that runs on PHP 8.1 or 8.2. That is a normal consequence of a project tracking supported PHP releases, but it does mean an adopter on an older runtime has to stay on the previous line. The release history shows how that plays out in practice, with 5.0.1 released on 2025-03-27, 5.1.0 on 2025-05-28 and 5.2.0 on 2026-03-19, and then the work moving to the 6.x branch. The last push to the repository was on 2026-07-24 and it is not archived, so the 6.x line is where current changes land. The CHANGELOG.md file at the root is where the differences between those lines are recorded, and it is the file to read before planning an upgrade across a major version.

One Composer command and a documentation site

Installation is a single Composer requirement:

``` bash composer require league/container ```

That is the whole install, because there is nothing to compile and no configuration file to create, which is the point of a package that is a handful of classes implementing an interface. The documentation lives at container.thephpleague.com and is generated with Jekyll, and the README notes that contributions to it are made in the docs subdirectory of the repository, so the documentation is versioned alongside the code rather than kept in a separate system. The repository also carries a downloads badge pointing at the Packagist listing for league/container, and a latest version badge pointing at the GitHub releases, which is the fastest way to see whether a release exists for the branch you are on.

How the testing and static analysis are set up

The quality tooling is described in a single line, that testing includes Pest and PHPStan at level 8, and it is run with the Composer script:

``` bash $ composer test ```

Level 8 is the highest PHPStan level and it is a demanding target for a library this small, which tells you something about how the maintainer treats the codebase. The repository makes that tooling visible rather than implied, with a phpstan.neon holding the static analysis configuration, a phpunit.xml for the test runner configuration, and a .php-cs-fixer.php for code style, alongside an .editorconfig and a .gitattributes. There is a bin directory for the project binaries and a tests directory for the suite, and a docs directory that, as noted, doubles as the source of the published documentation. For a contributor the practical instruction is in the CONTRIBUTING.md file linked from the README, and the CHANGELOG.md at the root records what changed.

Security reporting, credits and the licence

The security policy is short and specific. If you discover a security related issue, the README asks you to email [email protected] instead of using the issue tracker, which is the right channel for a vulnerability in a component that other people's applications will depend on. The credits section names Phil Bennett as the author, links the contributors list, and then names the Orno\Di contributors, which is a nod to the library whose lineage and API shape this container carries forward. The licence is the MIT Licence, with the text in LICENSE.md at the root. Nothing in the repository is vendor specific, and there is no proprietary edition or paid tier, and it is easy to state plainly for a dependency that ends up inside a commercial application, because MIT imposes no obligation on the applications that embed it.

Where a container like this fits, and where it stops

The limitation is structural rather than a defect. This is a container, not a dependency injection framework, so it gives you a place to register and resolve services and nothing more. Auto-wiring, which infers constructor arguments from type hints, and service configurators, which wire a whole object graph in one call, are features of larger frameworks, and the README does not mention them, which is a good sign that they are not there. The other boundary is the PHP floor, already covered above, and it interacts with the first, because a project that cannot upgrade PHP is usually a project that also cannot adopt a framework with a modern dependency injection story. The alternative to this package is not another small container but the container that already ships inside your framework, and the difference in approach is precisely the PSR-11 contract. A framework's own container can do more, because it is coupled to that framework's lifecycle and can resolve framework specific services, and it can do less in one respect, because code that depends on it cannot be lifted out. A PSR-11 container in a library keeps that door open.

Editorial conclusion

league/container fits a library or a small application that wants a dependency injection container without committing to a framework, because PSR-11 compliance means anything you write against it can move to another container later, and it fits a team that prefers the container to be a readable dependency rather than a framework feature. It is the wrong choice for a project still on PHP 8.1 or 8.2, since the current line requires PHP 8.3, 8.4 or 8.5 and the older 5.x releases are the ones that cover earlier versions. It is also a poor fit if you want auto-wiring or a service configurator, because the container is deliberately small. Before you adopt it, read the documentation for the API surface, since the README covers installation, testing and licensing rather than the container itself, and check which branch you are pinning.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. thephpleague/container on GitHub