AdapterMan runs an existing PHP app on Workerman unchanged

The premise is that a front controller is enough to run anywhere

AdapterMan's claim is narrow and testable. If your application or framework follows a Front Controller pattern, the README states there is a 99 percent chance it will work out of the box, with no modification to a single line of code in the framework or application. The named compatible frameworks are Symfony, Laravel, CakePHP, Yii2, Slim, KumbiaPHP, ThinkPHP, Leaf, FlightPHP, Wolff and Phpixie, and more are being tested. The mechanism is Workerman, the async event driven PHP runtime, and AdapterMan's job is to make an existing application reachable through it. The audience is therefore a developer with a working PHP application who wants to change how requests are served, not to change what the application does. The minimum requirements are PHP 8.0 or higher for AdapterMan 0.7, and PHP 8.1 for AdapterMan 0.7, which is a slightly awkward split that the README states as-is.

Two files carry the whole integration

The integration surface is deliberately tiny. The README gives the file tree where the two new files go, alongside the app directory, the public directory, vendor and composer.json.

.
├── app(dir)
├── public(dir)
├── vendor(dir)
├── composer.json
├── server.php
└── start.php

The server file is the Workerman entry point, and it initialises Adapterman, creates an HTTP worker bound to 0.0.0.0:8080 with a count of 8 processes, and runs the application's start file on worker start.

<?php

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

use Adapterman\Adapterman;
use Workerman\Worker;

Adapterman::init();

$http_worker                = new Worker('http://0.0.0.0:8080');
$http_worker->count         = 8;
$http_worker->name          = 'AdapterMan';

$http_worker->onWorkerStart = static function () {
    //init();
    require __DIR__.'/start.php';
};

The worker count of 8 is the concurrency knob, and the onWorkerStart hook is where you would put initialisation that must run once per process, which is the point where a legacy application that assumed one request per process starts to need attention.

The front controller recipe is per framework, and that is where the work is

The README is direct that the front controller is different for every framework and application, and that the project publishes recipes for popular ones, with files for Symfony, Laravel, Lumen and Slim under recipes/. The recommended layout is a start.php with the original index.php left in the public directory, which has a useful consequence: the same application can be run with Workerman and with php-fpm at the same time, so you can put the new runtime behind a path or a host and compare, or roll back by pointing a vhost back at the original entry point. That dual-running property is the single most operationally valuable thing here, because it converts a risky runtime migration into a routing change you can reverse in seconds.

The published numbers compare runtimes, not code

The README carries a table comparing php php-fpm against php workerman across a set of operations, and a second set of Techempower results for Symfony 6 and Laravel 8 with a full ORM. The direction of the difference is consistent across every row, and the gap is widest on plain text and JSON responses and narrowest on the multiple query case. The point of the table is not the absolute figure, since those depend on the machine, but the shape: moving the request loop into a long running process removes a large constant cost per request, and the more your handler does database work, the smaller the relative gain becomes. Slim 4 appears with and without an ORM, and the variant with the database class optimised for Workerman shows higher figures on the query heavy columns than the unoptimised one, which is the clearest hint that the runtime is not a drop-in free lunch for database bound work.

Shared nothing mode is experimental and the author says so

The newest section of the README is a Workerman shared nothing mode, described as being tested and still experimental. The idea is that each request is independent and loads the .php file, in the way PHP-FPM does, while using the same .php files as before. That is a different trade from the default mode. In the default, the application stays resident in a worker process, which is where the per-request savings come from and where the risk of leaking state between requests lives. In shared nothing, each request gets a fresh process state, which matches legacy expectations but gives up some of the residency benefit. The accompanying table compares php php-fpm against php workerman on that basis, and the multiple query and updates columns are where the difference narrows. Anyone reading this section should treat the mode as a development in progress rather than a settled option.

The session caveat is the one to read twice

The README contains a section on session issues, and it is the most useful paragraph in the document because it states a limitation rather than a capability. The author says the library has been used internally for over two years to run legacy applications with Workerman, that the work began primarily for APIs and microservices, and that as a result session handling was not a key focus during testing, so the session functionality may not be as thoroughly tested or optimized as other features. The request is to report problems so compatibility can be investigated. What follows shows what does work, with a login flow working under Symfony and Laravel, a Laravel Orchid admin panel, and Drupal serving public pages. Public pages are a much weaker signal than an authenticated session, and the honest reading is that the library is proven on stateless request handling and unproven on stateful ones. The repository also contains a cli-php.ini file, and the README shows how to select a different ini directly on the command line, which matters for extensions that only load under a specific configuration.

Day to day operation is the Workerman command set

Once the two files exist, the operational surface is Workerman's own command set, which the README lists in full.

php server.php start
php server.php start -d
php server.php status
php server.php stop
php server.php restart
php server.php reload

The daemon flag, the status query, and the stop, restart and reload variants are the ones you will actually use, and the reload with the global flag is how a long running worker picks up changed code without dropping every connection. Installation is a single Composer command, and the README states that Workerman is installed automatically at the same time.

composer require joanhey/adapterman

The licence is MIT, with the LICENSE.txt file at the repository root, and the source lives in src/ with a tests/ directory, a phpunit.xml.dist and a recipes/ folder. The last push was on 2026-04-25, and the release tags are 0.7.1 from 2025-05-06, 0.7.0 from 2025-01-08 and 0.6.1 from 2023-04-16, so the code is being changed on the default branch while the tags move on a slower cadence.

Editorial conclusion

AdapterMan suits a team with a conventional front controller PHP application that wants the request handling characteristics of a long running event driven process without a rewrite, and it suits a developer willing to write the small front controller and start file themselves. It is the wrong tool for an application that keeps state in globals between requests, for a codebase whose session handling is load bearing and untested, and for anyone who expects a packaged runtime rather than a thin shim. Before adopting it, read the session section of the README carefully, because the author states the session functionality may not be as thoroughly tested as the rest, and confirm the framework recipe for yours exists under recipes/ before committing. The last push was on 2026-04-25 and the current release is 0.7.1 from 2025-05-06.

Frequently asked questions

Official sources

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