Octane keeps your Laravel app in memory and makes you rewrite your service providers

What the README actually promises, in one paragraph

The README is 1,843 characters long and most of it is badges and links. The substantive paragraph says Octane serves your application using high-powered application servers including FrankenPHP, Open Swoole, Swoole and RoadRunner, and that it boots your application once, keeps it in memory, and then feeds it requests. Everything else is a documentation link, a contributing guide, a code of conduct, a security policy and the MIT licence line.

That brevity is the first thing to notice, because it is unusual for a package with 4,042 stars and 347 forks. Most projects this size carry an architecture diagram and a tuning guide. Octane's own documentation lives at laravel.com/docs/octane, and the README's only job is to tell you the package exists, name the four servers, and get you to the real page.

It also means the honest evaluation has to lean on other evidence. The repository tree is more informative than the README. There is a `config/` directory for server settings, a `fixes/` directory whose name is a warning, a `bin/` directory for the CLI entry point, `UPGRADE.md` for major version transitions, and `phpstan.neon.dist`, which shows the package analyses itself at a strict level. The topic tags are `laravel`, `octane`, `roadrunner` and `swoole`, so two of the four supported servers have dedicated tags while FrankenPHP does not, which tells you something about when each was added.

The trade is memory for per-request bootstrap work

To be precise about what gets faster: the application boot sequence. Under PHP-FPM every request goes through a fresh process, which means every request re-reads configuration, re-registers service providers, re-resolves the container bindings and re-loads your classes. Octane replaces that with a worker process that does the boot once and then loops, handing it each incoming request.

For an application with heavy service providers, lots of configuration binding, or expensive bootstrap work of any kind, that difference is large enough to change the shape of your hosting bill. For an application that was already thin on boot, the difference is smaller, and the measurement you care about is per-request latency under realistic data rather than a synthetic route that returns a string.

The mirror image of that gain is where the work goes. A long-lived container is, by construction, a container that remembers things. Anything you put into a singleton, a static property, a global helper or an object held in a service provider property is now shared across every request that worker serves. Under FPM you could get away with a surprising amount of this because the process died immediately afterwards. Under Octane the same code leaks state from one user's request into the next one, which is the classic source of the bug reports you will find in any long-lived worker system.

This is why the `fixes/` directory exists. Those are shipped patches that reset known stateful framework pieces between requests, and they are the visible edge of a design where correctness depends on knowing what your container kept.

Recent releases are all about workers and process handles

Three releases in the last six weeks show what maintenance on this package actually looks like, and none of them are about performance work.

v2.20.0, published 2026-09-22, made the RoadRunner worker command configurable and absolute-path safe. That is a small change with a large blast radius, because a worker command that assumes a working directory only works if your process manager happens to start it from the directory Octane expects. Making it configurable and absolute-path safe is the difference between deploying and not deploying.

v2.19.1, on 2026-08-18, cast `$managerProcessId` to an integer inside Swoole's `ServerProcessInspector::stopServer()`. A type cast as a release is a small reminder of the cost of living on top of an extension layer you do not control, where a value that came back as a string from a process boundary will quietly produce wrong comparisons.

v2.19.0, on 2026-08-11, bundled a Dependabot bump of actions/checkout from 7.0.0 to 7.0.1 and added an override for the `server` artisan command. Both entries are unremarkable individually, which is exactly the signal that you are reading a mature package with a functioning maintenance loop rather than a project still looking for its footing.

The pattern across all three is process lifecycle. That matches the architecture: if the interesting cost was in making requests faster, the releases would be tuning notes, and they are not.

Four servers, and the choice is not neutral

The README names FrankenPHP, Open Swoole, Swoole and RoadRunner. Choosing between them is a decision about what you want to operate, and it is not a decision the README helps with at all.

Swoole in both its original and Open Swoole form is a PHP extension, which means a compiled dependency in your deployment image and a compatibility surface you inherit from a C project. Open Swoole specifically exists as a fork with broader licensing, and if your organisation has a policy about extensions in production this is where it lands.

RoadRunner is written in Go and talks to your application over its own RPC layer rather than embedding PHP. The consequence of that design is visible in the v2.20.0 release: the worker command has to be made configurable and absolute-path safe, because Octane is launching a child process from another binary. In exchange you get a very ordinary compiled binary to deploy.

FrankenPHP is built on Caddy and serves over a modern HTTP stack, which makes it the easiest of the four to place behind a familiar web server and the one with the most recent ecosystem momentum behind it. The topic tags still favour Swoole and RoadRunner, so if you are starting fresh the README's own emphasis is not pointing at FrankenPHP.

Where to evaluate this without being misled

Start from the questions the documentation will ask you rather than the number in the description. The description reads 'Supercharge your Laravel application's performance', which is true in the way marketing copy is true: the measurement depends entirely on how expensive your boot sequence is. An application whose providers do real work in `register()` and `boot()` will see a large difference. An application that was already near the floor of PHP-FPM will see less, and will pay the state-management cost either way.

Second, read the documentation section on flushing the container before you commit to a production migration. The existence of `fixes/` tells you the framework needs help here, and a package of patched framework behaviour is a dependency whose failure mode is subtle: not a crash, but two requests sharing something they should not have.

Third, decide where the workers run and who restarts them. A long-lived process that leaks memory will eventually need recycling, and whether that is your supervisor, your orchestrator or the server itself is an operational question the README does not touch.

On the maintenance numbers: 4,042 stars, 347 forks, 20 open issues, last pushed 2026-09-22, MIT licensed, not archived, default branch `2.x`. Twenty open issues on a package this widely deployed is a good sign, and a last push the same day as the newest release means the repository is live rather than nominally maintained. The gap between the tiny README and the healthy release cadence is explained by ownership: this is a first-party Laravel package whose documentation budget is spent on laravel.com instead of in the repository.

Editorial conclusion

Octane is the shortest path to a large improvement in how a Laravel application handles throughput, and the reason it stays a package rather than a default is that the improvement comes with a permanent behavioural change. Serving from a long-lived worker means every piece of state you leave in the container is now shared across requests, which is why the `fixes/` directory exists and why the interesting maintenance commits are things like making the RoadRunner worker command absolute-path safe. The README is deliberately tiny because the real documentation is on laravel.com and that is a fair division of labour for a package owned by the framework team. Pick FrankenPHP or RoadRunner as your first server, read the section on flushing state before you ship, and measure with a realistic dataset rather than a hello-world route.

Frequently asked questions

Official sources

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