Spiral Framework keeps PHP resident and its application elsewhere

Where PHP stays resident and RoadRunner takes over

A PHP request usually ends with the response: the worker process is torn down and everything the request built goes with it. Spiral Framework inverts that. Its execution model is a hybrid runtime, so services that must outlive a single request, GRPC, Queue and WebSockets among them, are handed to the RoadRunner application server, and the PHP code of your application stays in memory permanently. That is the argument for teams whose PHP work is not only HTTP. The page dates the project to 2013, calls the result long-living and full-stack, and publishes it as a group of over sixty PSR-compatible components, so the intended reader already works in PSR interfaces and wants the framework to hand those interfaces back rather than wrap them.

Resident workers turn a memory leak into a server-wide problem

Resident code does not get the cleanup a per-request model hands you for free. Whatever the framework or your own classes park in a static property, a long-lived object or a closure survives until the worker recycles, so a leak that used to vanish at the end of a request now accumulates for the life of the process. The page counts anti-memory leak tools among the shipped pieces, which is an admission that the leak surface is real rather than hypothetical, and it puts the remedy outside the framework, in how RoadRunner is configured to recycle workers. Nobody spots this on a short endpoint, so leak hunting here needs a process that runs long and a profiler that survives across requests. If your workload is a handful of stateless routes, this architecture buys you a second failure mode to watch.

Sixty-plus components share a single src directory

Component count and directory listing do not match at first glance. Over sixty components would normally mean sixty directories, yet the top level of this repository holds one `src/`, one `tests/` and a `builder/`. Everything ships as a single Composer package, which keeps versioning simple and makes the install heavy, since you take the whole set or none of it. Component boundaries live in namespaces rather than in the filesystem, and class discovery is described as static analysis rather than a filesystem scan. The cost appears when you need one piece, because the ORM lives in its own repository as `cycle/orm` and workflow scheduling lives behind `spiral/temporal-bridge`.

spiral/app holds the skeleton this repository does not

Here is the first practical surprise: the README carries no install command at all. No Composer one-liner, no configuration snippet, no runtime list to copy. What it does carry is a link to the application installer at `spiral/app`, and the services that make up the hybrid runtime are configured in RoadRunner rather than in a web root shipped here. So the path to a running application starts in a second repository and comes back to this one as a dependency. Two details matter before you plan around them. The build badge at the top of the page reads the PHP requirement from Packagist instead of printing it, so the constraint you must satisfy sits inside `composer.json`. And the configuration the page never shows is expected to be found at `spiral.dev/docs`, which the project treats as its documentation home.

The root is analysis and refactoring config, not application code

Read the root listing as a maintenance surface rather than an application. `psalm.xml` and `psalm-baseline.xml` sit side by side for static analysis, `phpcs.xml` and `.php-cs-fixer.dist.php` cover coding style, and `rector.php` is set up for automated refactoring. `infection.json` configures a tool the page never names, `phpunit.xml` runs the suite, and `codecov.yml` with `.scrutinizer.yml` report on it. `monorepo-builder.php` and `builder/` exist to split the monorepo into packages, and `structarmed.php` sits at the root with no explanation anywhere on the page. None of that is application code. It is the footprint of a library with a large suite that gets cut into packages for every published version, so an upgrade costs you tooling and dependency changes rather than an application rewrite.

The bridges table names six packages and no versions

The Bridges table has a column headed Current Status, and every cell in it is a Packagist badge image instead of a version string. Nothing on the page tells you which `spiral/roadrunner-bridge`, `spiral/cycle-bridge`, `spiral/temporal-bridge`, `spiral/data-grid-bridge`, `spiral/sapi-bridge` or `spiral/nyholm-bridge` you would install, or whether those packages move together with the core. Six separate dependencies with no stated compatibility window make an upgrade a six-package problem that you resolve in your `composer.json`, not here. It also means the headline capabilities do not all ship in one box: GRPC runs through the RoadRunner bridge, the ORM through the cycle bridge, and Temporal workflows through the temporal bridge.

Two minor lines were patched on the same July date

Upgrading a project that carries its whole component set in one package has a measurable cost, and the tag list shows how it is paid. The root carries the change plumbing for a monorepo in `CHANGELOG.md`, `monorepo-builder.php` and `builder/`, and the history lines up with that: 3.17.1 and 3.13.1 both dated 2026-07-13, then 3.17.2 on 2026-08-05, and a last push on 2026-10-06. Two different minor lines patched on one day reads as concurrent branch support, which is good for patch delivery and awkward for your constraint file, since you may be holding either line. On licensing, the repository ships an MIT `LICENSE` and names Spiral Scout as maintainer, so nothing here imposes copyleft on an application you build with it, and reading that file is the only legal step involved.

RoadRunner alone, or cycle/orm alone, is the smaller choice

Both halves of Spiral exist on their own, and for plenty of projects that is the right answer. RoadRunner is a separate repository with its own site, and using it as a PHP application server gives you resident workers, queues and GRPC without taking on a framework's conventions and directory layout. The ORM has the same shape, since `cycle/orm` is a standalone repository and a team that wants that ORM can reach it without the bridge. The reverse holds too. Spiral is the heavier choice, and it earns that weight when one codebase needs an HTTP kernel, a queue consumer, a GRPC service and workflow scheduling sharing a single dependency graph. If you need only one of those four, take the one you need.

Editorial conclusion

Adopt Spiral when one codebase must run an HTTP kernel, queue consumers, GRPC and workflows together, and you are willing to own a resident process that needs leak monitoring. Skip it for a stateless service, or when six bridge packages with no stated versions on the project page are an unacceptable dependency. Check the PHP constraint inside `composer.json` first, then read one full request path at `spiral.dev/docs`, and watch the heap of a single queue worker through a day of real traffic before the design hardens around it.

Frequently asked questions

Official sources

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