Containers are all the rage these days, but containerising PHP applications has always felt a bit… clunky. In the past, it’s been a choice between complex networking but efficient resource use (nginx + fpm), or idiomatic containerisation and resource hog (apache + phpmod). With the advent of new PHP servers like Swoole and Roadrunner, and the tools like Laravel Octane that package them up, we have a new alternative that gives us idiomatic containers and great performance.

When I say “idiomatic containers”, what I mean is a container that lets you run the entire application. If you run Apache or Octane, you can run the container and have an HTTP server. That’s an idiomatic container.

Quite a few years ago, a lot of PHP applications chose to move off Apache to the more performant nginx web server, combined with the resource-efficient php-fpm server. When containerising this, however, you end up needing two containers, one for nginx and one for FPM. This isn’t ideal, as you now require networking between containers to run your application, and if you want to run multiple copies of the container (replicas), you need to make sure you increase both the number of nginx and FPM containers.

Now, we have new alternatives, through Laravel Octane, which wraps around Swoole or Roadrunner, whichever you choose to use. Both Swoole and Roadrunner are PHP application servers and network libraries, opening up the possibility to write performant HTTP servers straight in PHP, rather than outsourcing that to a dedicated tool like nginx. This means, like in most other programming languages, you only need the single container to run the application. This lets you build resource-efficient and performant web services in PHP.

However, writing servers in PHP brings along a problem common elsewhere that most PHP developers have never had to worry about - long-running processes and asynchronous programming. In regular PHP web applications, you get a brand new PHP process for every request. In an Octane application, this isn’t the case. This means that any singleton you bind exists across requests, so relying on singletons to share state becomes a lot more dangerous, as you might end up sharing sensitive information like the “current user” to a completely different request that isn’t even authenticated. In addition, since the application is maintained in memory between requests, you can run into memory leaks if storing data on static properties. The Octane documentation has excellent documentation on both state management and memory management. If you can work with these caveats, you can benefit greatly from moving to Octane.

If you want to simplify the operations of your containerised PHP applications, there’s really only one choice. Laravel Octane is a no-brainer with all it provides, and how easy it makes maintaining and deploying containerised applications, whether that is with Docker, Kubernetes, or on a serverless platform like Lambda.