imi, a PHP framework for long-connection microservices that stopped being maintained

The maintenance notice comes before the feature list

The most important sentence in the project documentation is a blockquote, and it is placed high up: the project stopped maintenance on 2025-12-31 at 23:59:59, existing projects may continue to use it, and new projects are not recommended to use the imi framework. There is some tension in the record, since the last push to the repository was on 2026-07-31 and the release v2.1.66 carries that same date, while the previous release v2.1.65 is from 2025-11-14. So the branch kept receiving work after the notice, but the pace tells its own story, with a gap of about eight months between the two most recent releases. The default branch is 2.1, and the project dates from its first release on 2018-06-21. Any evaluation should start from that notice rather than from the feature list, because the feature list is the reason someone would consider the framework and the notice is the reason they probably should not. The scaffolding commands are the quickest way to see the shape of it.

composer create-project imiphp/project-http:~2.1.0
composer create-project imiphp/project-websocket:~2.1.0
composer create-project imiphp/project-tcp:~2.1.0

One framework, many container environments

The premise of imi is that a PHP project which needs long-lived connections should not have to leave PHP. The framework is described as supporting distributed microservices with long connections, and it can run inside PHP-FPM, Swoole, Workerman and RoadRunner. That list matters, because it separates imi from a Swoole-only framework: the same application code can sit behind a traditional PHP-FPM setup or behind one of the event-loop runtimes. The stated use cases are internet microservices, instant messaging chat, and the internet of things, and the project lists deployments in a cultural tourism e-commerce platform, an IoT charging cloud platform, a parking cloud platform, payment, SMS and wallet microservices, a card game server and a data migration service. The runtime requirements are stated tightly: Linux, since Swoole does not run on Windows, PHP 7.4 or newer, Composer 2.0 or newer, Swoole 4.8.0 or newer, plus Redis and the PDO extension.

The component list is the argument for the framework

The breadth is the pitch, and the list is long enough to be worth reading as a map of what a Chinese enterprise PHP stack tends to need. On the data side there is MySQL, PostgreSQL, Redis, a self-developed ORM the documentation calls unusually good and easy to use, connection pools, cache, lock, shared memory, a Snowflake ID generator, InfluxDB and TDengine. On the server side there are Web API, Web MVC, WebSocket, TCP Server, UDP Server, HTTP2, MQTT and gRPC. On the framework side there is a container, dependency injection, AOP, events, async support, command line, configuration, context, cron, a facade, validators, logging, timers, permission control, Swagger, Hprose, macros, rate limiting, Smarty templates and a Workerman gateway. Message queues appear as RabbitMQ, Kafka and Redis. The microservices layer adds Nacos and etcd as configuration centres, Nacos service registration and discovery, Swoole Tracker, Zipkin, Jaeger, Prometheus, service metric monitoring through InfluxDB and TDengine, and load balancing. It is a complete stack in one repository, which is exactly the appeal and exactly the maintenance problem.

How the projects are scaffolded and where the docs live

Getting started is a set of composer templates, one per protocol, and the version constraint pins the 2.1 line. There are templates for an HTTP server, a WebSocket server, a TCP server, a UDP server, a gRPC project and an MQTT server project, each created with a create-project command against the corresponding imiphp project package. That tells you something about the framework's shape: a protocol is a starting point rather than a configuration detail, and the same runtime serves all of them. The full development manual is hosted separately at doc.imiphp.com for the 2.1 version, and the project also runs free video tutorials, a free 2.0 basics series, an eleven-part 1.0 introductory course and an advanced course on building a gomoku game server, along with a Zhihu column. For Docker, the recommendation is the official Swoole image rather than a project image, and there is a separate imi-admin skeleton for administrative backends, hosted on Gitee alongside a set of third-party extensions for permission control, a registry, modular routing and a ThinkPHP6 validator.

The repository shows how a project is maintained

The tree is a good indicator of engineering discipline. There is a `src/` directory for the framework code, `tests/`, `config/`, `dev/`, `doc/` and `mddoc/`, and a `website/` directory, which suggests the documentation site is generated from the same repository. Static analysis is configured twice, with a `phpstan.neon` and a separate `phpstan-components.neon` for the component directories, driven by a `phpstan.sh` script, and code rewriting is set up with `rector.php` and a `rector.sh`. Style is handled by a `.php-cs-fixer.php` configuration, and there is a `package.json` whose only dependency is the markdownlint CLI, which is used to check the documentation rather than the code. The `split-repository/` directory suggests the code is arranged so parts can be split out, and `.editorconfig`, `.markdownlint.json` and a `.gitattributes` file fill out the housekeeping. The presence of a `config/` directory at the root also suggests the framework ships its own configuration surface rather than expecting everything to be set by the application.

Licence, ecosystem and what a new project should do instead

The licence is the Mulan PSL v2, a permissive Chinese open source licence, and the licence identifier in the repository metadata is a custom one that GitHub cannot classify, so the LICENSE file is the text to read. The acknowledgements name doctrine/annotations for annotation processing, and then PHP and Swoole in terms that make the dependency structure obvious. The community channels are a QQ group, a WeChat group and a donation page, and the project collects published case studies through a submission format that asks for a project name, description, link and contact details, which is a Chinese enterprise software vendor pattern rather than an open source community pattern. For a new project, the project own advice is the relevant part, and it is to not use imi. The pragmatic reading is that this repository is now a reference implementation and a dependency risk rather than a foundation to build on, and that its most useful remaining role is documenting what a full-stack PHP realtime framework in the Swoole ecosystem looked like, and how much of it there is to maintain when you inherit one.

Editorial conclusion

Adopt imi only if you are already maintaining a project built on it and need to understand its shape before you plan a migration off it, and skip it for anything new, because the project's own notice says it stopped maintenance on 2025-12-31 and does not recommend new projects use it. Verify three things before you rely on it: the exact PHP and Swoole versions your deployment has, since the framework requires PHP 7.4 or newer and Swoole 4.8.0 or newer and will not run on Windows under Swoole; which components your project actually touches, because a framework this wide is expensive to audit; and the terms of the Mulan PSL v2 licence, which is not one of the licences GitHub can classify and which the LICENSE file in the repository is the authority on.

Frequently asked questions

Official sources

1. imiphp/imi on GitHub
2. Issues
3. Project website
4. README
5. Releases