Slim 4: one composer line, five PSR-7 implementations, and decorators you did not install

One composer command installs the framework and leaves the message layer to you

The whole install is:

composer require slim/slim

That pulls Slim and all required dependencies, and the README states that Slim requires PHP 7.4 or newer. It gives a floor and no upper bound, and the version it documents is the v4 documentation, matching the 4.x default branch. What the command does not give you is a message layer. Slim requires you to choose a PSR-7 implementation and a server request creator before the framework can run, and the README names five candidates with a judgment on each: Slim-Psr7 as the Slim implementation, httpsoft/http-message with httpsoft/http-server-request described as the fastest, strictest and most lightweight available, Nyholm/psr7 with Nyholm/psr7-server whose performance is almost the same as HttpSoft, Guzzle/psr7 which the Guzzle Client uses and which carries extra functionality for stream and file handling, and laminas-diactoros as the Laminas implementation. Those judgments are about message objects, not frameworks.

Auto-detection boots only when one of five package pairs is present

AppFactory::create() and App::run() can work without you building a ServerRequest by hand, but only after a PSR-7 implementation is installed. Each candidate has its own command:

composer require slim/psr7
composer require httpsoft/http-message httpsoft/http-server-request
composer require nyholm/psr7 nyholm/psr7-server
composer require guzzlehttp/psr7
composer require laminas/laminas-diactoros

Two of those are pairs, which is the first trap: installing http-message without http-server-request, or nyholm/psr7 without its server request creator, leaves you short one half of what auto-detection expects. Slim-Psr7, Guzzle/psr7, and laminas-diactoros are single packages. For a reader, the practical consequence is that the second package in each pair is not optional polish; it is the difference between a bootstrap that runs and one that does not.

Slim-Http wraps your request and response without being asked

Slim-Http is a set of decorators for any PSR-7 implementation, recommended for use with Slim, installed with:

composer require slim/http

Once it is present, the ServerRequest and Response decorators are detected and applied by the internal factories, so your objects come back wrapped even though your code never asks for a wrapper. There are two separate switches for turning that off:

<?php

use Slim\Factory\AppFactory;
use Slim\Factory\ServerRequestCreatorFactory;

AppFactory::setSlimHttpDecoratorsAutomaticDetection(false);
ServerRequestCreatorFactory::setSlimHttpDecoratorsAutomaticDetection(false);

$app = AppFactory::create();

Note that the two factories are configured independently, and the README does not say whether disabling detection on one implies the other. It also does not say what the decorators add.

A Hello World that needs a public directory and PHP's own server

The entry point is a hand written file at public/index.php:

<?php
use Psr\Http\Message\ResponseInterface as Response;
use Psr\Http\Message\ServerRequestInterface as Request;
use Slim\Factory\AppFactory;

require __DIR__ . '/../vendor/autoload.php';

// Instantiate App
$app = AppFactory::create();

// Add error middleware
$app->addErrorMiddleware(true, true, true);
$app->get('/hello/{name}', function (Request $request, Response $response, array $args) {
    $response->getBody()->write('Hello, ' . $args['name']);
    return $response;
});
$app->run();

The error middleware is added with three booleans set to true, and routes are closures receiving the request, the response, and an args array for placeholders such as {name}. To try it, the README points at PHP's built in server:

php -S localhost:8000 -t public

Two things follow. That command is framed as a quick test, and the README says nothing about serving this in production, deferring instead to its own web server documentation page. And the three true flags mean the sample starts with error details switched on, which is a sensible default for a first run and a poor one to carry into production unchanged, since the first flag controls whether error details are displayed; disable it in production.

Four analysis configs at the root, none of them runnable without the dev install

The repository root carries the full quality apparatus for a small library: phpcs.xml.dist for coding standards, phpstan.neon.dist for static analysis, psalm.xml for a second analyser, phpunit.xml.dist for the test runner, and .coveralls.yml for coverage reporting, alongside .editorconfig and a CHANGELOG.md. CI runs a tests workflow scoped to the 4.x branch, and the coverage badge is pinned to the same branch. Running any of it locally starts with the same three commands:

git clone https://github.com/slimphp/Slim
composer install
composer test

The README is explicit that the test suite needs all development dependencies installed first, which means a plain composer require slim/slim gives you a project with none of this checking available.

A 4.x default branch that a 3.x release shipped alongside months later

The default branch is 4.x and every README example targets the v4 documentation, yet the release history includes 3.13.0 on 2026-04-28, shortly before 4.15.2 on 2026-05-22 and 4.15.3 on 2026-09-01. The last push is dated 2026-11-01, two months after the newest tag, 4.15.3 on 2026-09-01. An UPGRADING.md sits at the root, which is where a team moving between the two lines has to look.

Security reports bypass the tracker, funding runs through two channels

The project asks that security problems go to [email protected] rather than to the issue tracker. Ordinary discussion has its own channels instead: a Slack workspace, a Discourse support forum, and an awesome-slim resource list maintained elsewhere. Money runs through two routes, an OpenCollective page that takes individual and organization contributions, and a Tidelift subscription offering commercial support and maintenance for the packages you depend on, positioned as paying the maintainers of the exact dependencies you use. Governance files sit alongside them in CONTRIBUTING.md, CODE_OF_CONDUCT.md, and MAINTAINERS.md. For an adopter, the split is worth naming plainly: the maintenance of a framework that routes all traffic through your server is funded partly by subscriptions and partly by donations.

Editorial conclusion

Slim fits an API or a small application when you want the routing layer and nothing else, and you are willing to choose a PSR-7 implementation deliberately rather than inherit one from a full stack. Be less comfortable with it when you need a bundled ORM, session layer, or mailer, or when your team cannot afford the tuning that auto-detection and decorators introduce. Before you start, decide which PSR-7 implementation you are adopting and pin it, check whether your PHP version clears the 7.4 floor the README states, read UPGRADING.md if you are moving from 3.x, and route security findings to the address the project names instead of opening an issue.

Frequently asked questions

Official sources

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