FrankenPHP worker mode keeps your application in memory between requests. A migration trial should check retained user state, required PHP extensions and what happens when the server process stops. Our repository run supplies build and package-check results, but it does not establish application correctness or a performance gain.
What FrankenPHP combines
The FrankenPHP README describes a PHP application server built on Caddy, with automatic HTTPS. It can also embed PHP in a Go application using net/http.
Worker mode is optional. The documentation describes Symfony and Laravel Octane integrations and a custom worker-script route. Keeping the application bootstrapped avoids repeating startup for each request. Whether that benefit justifies migration needs an application workload, which our measurements do not include.
What happened when we ran it
At commit 3b6ef0f on October 23, 2026, installation succeeded in 40 seconds and recorded 92 dependencies. The repository build command passed in 32 seconds. The test command failed after 12 seconds with exit code 1.
The sandbox configuration recorded 3 CPUs, 8 GB of RAM and the image label golang:1.24-bookworm. The checkout contained 605 files, approximately 40,839 source lines and 6.4 MB of data. The image label does not establish actual runtime or operating-system versions.
The Go summary contains 3 passing and 5 failing package results. The passing packages were internal/extgen, internal/phpheaders and internal/state. The root package, internal/testcli, internal/testext, internal/testserver and internal/watcher were marked build failed. These are package outcomes, not eight individual behavior tests.
The supplied tail lacks the compiler diagnostics behind those failures. Their cause and applicability to another environment remain unresolved. The log does not establish a missing dependency, incompatible PHP version or watcher-library problem. The successful repository build command also does not establish that a runnable server binary was produced or that a PHP application served requests correctly. The scan found 12 CI workflow files, a Dockerfile and a tests directory; their presence does not change the failed local test result.
State can outlive a request
The worker guide documents static variables, class static properties and globals persisting between requests. Arrays and objects outside the request handler persist too. A service that retains the current user's details therefore needs deliberate cleanup.
Most request superglobals reset between requests, but $_ENV does not. Changes to the working directory, default stream context and other documented runtime settings also persist. Symfony and Laravel Octane reset much of their own state, but the guide warns that applications may still need to reset their own services.
Before migrating, list services that store request-specific data. A useful application check is to alternate requests from different users through the same worker and inspect retained state. This is a proposed validation step, not a sandbox result. Monitor memory over repeated requests as well: the guide describes restarting workers after a configured request limit as a workaround for libraries that leak memory.
A hard memory limit can stop the whole server
The known-issues page documents a separate process-level risk. Since PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, exceeding memory_limit raises the fatal error at the next function call or loop iteration rather than stopping the script immediately. If allocations reach PHP's hard memory limit before that, PHP exits the process.
FrankenPHP serves all requests from threads of a single process, so every in-flight request is lost and the server stops until it is restarted. The documentation recommends a supervisor that restarts FrankenPHP, such as a Docker restart policy or systemd's Restart= setting, which it says is already set in the deb and rpm packages.
This is a documented operating risk, not a failure observed in our sandbox. Restarting workers after a request limit addresses the worker guide's memory-leak scenario; deployment planning must also account for a server process exiting at the hard memory limit. Check the PHP version and restart configuration in the deployment you intend to use. The sandbox image label does not establish which PHP version ran.
Check extensions and distribution compatibility
The known-issues page lists imap, newrelic and pcov as incompatible because they are not thread-safe. If your application requires one unchanged, that is a reason to retain another serving path.
The same page says the documented musl-based static binary and Alpine Docker images lack GLOB_BRACE. It recommends the GNU binary variant or Debian-based images when compatibility issues arise. For the README's local Docker HTTPS example, use localhost rather than 127.0.0.1. These documented limits do not establish the cause of our package build failures.
Choose a deployment route before interpreting the build
The README offers standalone binaries and Docker images. The source-compilation guide describes building with a compatible PHP library and thread safety enabled. A passing repository build command does not replace deployment checks for your application, extensions and configuration.
Documentation receives 4/5 on this review's scale: 1 means unusable instructions, 3 means useful guidance requiring reconciliation, 4 means clear guidance with explicit operating limits but deployment validation still outstanding, and 5 requires consistent coverage confirmed through the relevant deployment checks. The supplied guides explain persistent state, identify incompatible extensions and describe the hard-memory-limit shutdown risk with restart mitigation. We did not validate a packaged application deployment, so the assessment stops at 4.
The supplied GitHub API metadata, observed on October 24, 2026, records the repository's last push as October 23, 2026 at 19:17:05 UTC. Maintainer responsiveness and community support were not assessed; a push timestamp does not establish either.
Alternatives depend on the operating model
PHP-FPM is PHP's FastCGI process manager with configurable worker pools. Consider it when you want to retain a separate FastCGI deployment and its pool controls.
RoadRunner is a PHP application server and process manager written in Go and extended through plugins. Consider it when that plugin model fits the service you need to operate. We measured neither alternative.
For a FrankenPHP trial, start with an extension inventory and a list of services holding request-specific state. Check server restart arrangements, then validate repeated requests in the deployment route you intend to use. Our repository build command passed, but the failed package checks remain unexplained and application behavior remains unmeasured.