Slim 4: A PSR-15 Micro Framework for PHP APIs

What Slim Actually Solves for PHP Developers

Slim is a router plus a middleware dispatcher. The README describes it as a PHP micro-framework for writing simple web applications and APIs, and the repository's topics list PSR-15, PSR-7 and PSR-3, which tells you the intended shape: HTTP messages in, HTTP messages out, with logging left to a PSR-3 logger you supply. It is for developers who already know how they want to structure an application and only need the request-handling layer. A team building a JSON API with an existing database layer, an existing DI container, and an existing template engine gets a routing table and a middleware stack without a framework deciding their directory layout. The trade-off is explicit: nothing is decided for you, so nothing is provided for you either. There is no ORM, no migration tool, no view layer and no admin scaffolding in the package. If you want those, you are choosing a different category of framework.

The PSR-7 Choice Is the First Architectural Decision

The most consequential thing about installing Slim is that it does not ship a PSR-7 implementation by default. The README states you must choose one before you can get running, and lists Slim-Psr7, httpsoft/http-message with httpsoft/http-server-request, Nyholm/psr7 with Nyholm/psr7-server, Guzzle/psr7, and laminas-diactoros. This is a deliberate decoupling, and it is also the point where new users get stuck. AppFactory::create() and App::run() rely on auto-detection of an installed implementation, so if you install slim/slim alone and write the Hello World from the README, request creation has nothing to detect. The README's own wording is that auto-detection requires one of the listed implementations to be installed. The README also calls httpsoft/http-message the fastest, strictest and most lightweight implementation available and says Nyholm performs almost the same, but it publishes no numbers, so treat those as the project's characterisation rather than a benchmark. Slim-Http is a separate package of decorators for any PSR-7 implementation; the README recommends it and notes that its ServerRequest and Response decorators are applied automatically by the internal factories unless you disable detection with AppFactory::setSlimHttpDecoratorsAutomaticDetection(false) and ServerRequestCreatorFactory::setSlimHttpDecoratorsAutomaticDetection(false).

Installing Slim 4 and Serving a First Route

Slim installs through Composer and requires PHP 7.4 or newer according to the README. The first command pulls the framework, and the second pulls one PSR-7 implementation plus its server request creator, which is what makes AppFactory auto-detection work. The README gives these two commands verbatim:

composer require slim/slim
composer require slim/psr7

After that, the README's Hello World lives in public/index.php. It instantiates the app, adds error middleware, registers two GET routes, and runs. The route callback writes to the response body and returns the response, and the path placeholder is read from $args.

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

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

$app = AppFactory::create();
$app->addErrorMiddleware(true, true, true);

$app->get('/', function (Request $request, Response $response) {
    $response->getBody()->write('<a href="/hello/world">Try /hello/world</a>');
    return $response;
});

$app->get('/hello/{name}', function (Request $request, Response $response, $args) {
    $name = $args['name'];
    $response->getBody()->write("Hello, $name");
    return $response;
});

$app->run();

The README then says you may quickly test this using the built-in PHP server, with the document root pointed at public:

php -S localhost:8000 -t public

Requesting http://localhost:8000/hello/world displays "Hello, world" according to the README. If you get a failure about request creation instead, the PSR-7 package from the second command is the thing to check, not your route code.

Routing, Middleware and Error Handling in Practice

Routes are registered on the app object and matched by HTTP method and path pattern. The README's example registers $app->get('/hello/{name}', ...) and reads the placeholder from the $args array passed as the third callback parameter, which is how path parameters reach your handler. The handler signature is a PSR-15 style callable taking a ServerRequestInterface, a ResponseInterface, and the argument array; you write to the response body and return the response. Error handling is opt-in through middleware: the README adds it with $app->addErrorMiddleware(true, true, true). Those three booleans control whether error details are displayed, whether they are logged, and whether full stack traces are shown, and the README does not spell out which is which, so check the documentation before shipping. Leaving the first flag true in production is the obvious failure mode. Middleware is added to the app and executes as a pipeline around the route, which is the standard PSR-15 model and the reason Slim composes well with third-party middleware that targets that interface. Everything else, including dependency injection into route callbacks, is left to you or to a bridge package.

Where Slim Is the Wrong Tool

Slim gives you no persistence layer, no authentication system, no queue integration and no templating. A project that needs user accounts, an admin panel and database migrations on day one will spend its first week assembling packages that a full-stack framework ships configured. The absence of a default PSR-7 implementation is a second friction point: it is a design choice that keeps the core small, but it means a bare composer require slim/slim produces an application that cannot create a request until you add another package. On maintenance, the 4.x branch received release 4.15.3 on 2026-09-01 and the last push to the repository was on 2026-09-01, so the branch is being maintained. Note that 3.13.0 was released on 2026-04-28, which means the 3.x line still receives releases; if you find Slim 3 tutorials online, the construction pattern differs from 4.x and UPGRADING.md in the repository root is the document that covers the move.

Slim Compared with Laravel and Laminas

The related searches pair Slim with Laravel, and the difference is scope rather than speed. Laravel is a full-stack framework: it ships an ORM, a queue system, a templating engine and a CLI, and it expects your application to live inside its conventions. Slim ships a router and a middleware pipeline and expects your application to live wherever you put it. If your service is a thin HTTP layer over an existing domain model, Slim lets you keep that model untouched; Laravel would ask you to wrap it in Eloquent or a service provider. If you are starting from nothing and want batteries included, Slim makes you assemble the batteries. The PSR-7 decoupling also distinguishes Slim from frameworks that bundle their own HTTP layer: you can move between httpsoft, Nyholm, Guzzle and laminas-diactoros without changing your route definitions, because your handlers only see PSR interfaces. That portability is the concrete payoff for the extra install step.

Licence, Support Channels and Upgrade Cost

Slim is released under the MIT licence, which permits commercial use and modification; this is a description of the licence identifier in the repository, not legal advice, and you should read LICENSE.md before relying on it. The README points to a Slack workspace, a Discourse support forum and the website documentation, and asks that security issues be emailed to [email protected] rather than filed in the issue tracker. Commercial support is offered through the Tidelift subscription, which the README describes as covering the maintainers of Slim and other packages. Upgrade cost is the item to budget for: the repository carries UPGRADING.md, and the coexistence of a 4.x release line with an April 2026 3.13.0 release means both are live, so pinning the major version in composer.json matters. The test suite runs through composer test after composer install, per the README.

Editorial conclusion

Adopt Slim if you want a small, PSR-15 middleware pipeline and are willing to pick and wire your own PSR-7 implementation, error middleware, and container. Do not adopt it expecting an ORM, templating engine, or admin generator; those are not in the package. Before committing, verify that your chosen PSR-7 implementation satisfies AppFactory::create() auto-detection, and read UPGRADING.md if you are coming from Slim 3, because the 4.x line changes how the app is constructed.

Frequently asked questions

Official sources

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