When to Use a PHP Application Server

PHP application servers are experiencing a moment of rapid evolution, with FrankenPHP now officially supported by The PHP Foundation. Providing self-contained, all-in-one environments, PHP app servers deliver excellent results for specific use cases. However, despite their strengths, they also come with notable challenges, such as reduced flexibility and scalability.

In this blog, I walk through the core concepts of PHP application architectures, compare leading PHP application servers, and highlight ideal use cases where they shine. I also examine the limitations that come with using PHP app servers. Finally, I explore where a more modular and enterprise-ready approach may offer better flexibility, maintainability, and long-term support for your application needs.

PHP Application Servers: Overview

PHP servers act as the foundation of many PHP applications, ranging from simple servers to all-in-one PHP development platforms. Before we dive into the world of PHP application servers, let’s go through some of the basics.

What Is a PHP Application Server?

A PHP application server provides an environment for running PHP-based applications.

These servers vary in complexity depending on your required functionality, tools, and configuration.

Some PHP servers are extremely basic. Others provide additional functionality such as clustering services, debuggers, and automated tools for application monitoring and web-server configuration, which can save a lot of time and reduce the need for numerous third-party or open source technologies.

How to Set Up a PHP Application Server

The most common to set up a PHP application server is a roll-your-own approach, where you set up a web server and configure it to serve PHP. 

Apache and Nginx are the most popular when it comes to this approach, and they both have their own pros and cons.

Apache has been around for decades, making it mature, stable, and well-documented. It also has a built-in module for PHP processing (mod_php), which makes for a simpler configuration. However, it has relatively high memory usage pre-connection and slower performance when compared to Nginx, and its process-based architecture can be less efficient.

In contrast, Nginx is more modern, even though it celebrated its 20th anniversary in 2024. It has an efficient event-driven architecture for handling concurrent connections. With a relatively lower memory footprint, it has better performance under high load when compared to Apache. However, there’s no direct PHP processing, meaning it relies on PHP-FPM, and that means having to configure and run PHP-FPM alongside Nginx. PHP-FPM can be a great thing though, because it comes with many advantages, such as separate processes from web server (separation of concerns), better resource utilization, fine-grained process management, portability (easy to swap between web servers), and process pool management for scaling.

While some developers prefer the above for various reasons, there are also somewhat all-in-one PHP application servers that combine the PHP runtime and the web server. These types of application servers can dramatically improve performance (especially at scale), lower resource usage, and even add features not typically found in standard PHP environments.

Monolithic PHP Architecture vs. Microservices

Monolithic PHP architecture bundles all functionality into a single deployable unit. This model works well with modern PHP application servers like FrankenPHP, RoadRunner, and OpenSwoole, which boost performance through persistent workers and asynchronous handling. It's a simple, fast-to-deploy option ideal for teams prioritizing ease of development and centralized management.

Microservices split applications into independent services, each handling a specific function. PHP fits into this model via containers, APIs, and orchestration tools like Kubernetes. Mircoservices offer better PHP scalability, improved flexibility, and more control over the increasingly complex demands of modern PHP applications.

Mission-Critical PHP Made Possible

Ready to modernize your applications and future-proof your PHP? Take advantage of secure and supported runtimes, advanced observability and monitoring tooling, and much more.

About ZendPHP  Discover ZendHQ

PHP Application Server Comparison: FrankenPHP vs. RoadRunner vs. OpenSwoole

When exploring modern PHP application servers, FrankenPHP, RoadRunner, and OpenSwoole stand out from the rest. While FrankenPHP is the only PHP app server backed by the community, all three offer powerful features for boosting performance and scalability. The right option for your organization will depend on your goals, traffic demands, and many other factors.

Additionally, while each takes a unique approach to improving speed and efficiency, it's important to remember that these PHP servers are also relatively new to the ecosystem. As a result, they have a somewhat small community, lackluster documentation, and come with steep learning curves for developer teams.

FrankenPHP

FrankenPHP is built on top of the Caddy web server, which is a web server designed for ease of use, simple configuration, and automation of HTTPS. It’s a modern PHP application server, built with the Go language, designed to simplify deployment and enhance performance. By embedding the PHP runtime within the web server, it eliminates the need for FastCGI, leading to improved performance and access to advanced features, such as HTTP 103 Early Hints, HTTP/3, and others not typically available in standard PHP environments.

Use Cases for FrankenPHP

High-concurrency environments can leverage FrankenPHP’s multi-threading capabilities. If your application relies on zero downtime, FrankenPHP has you covered with its worker-mode and graceful shutdown features by allowing new workers to spin up and replace older ones without interrupting active connections.

Pros of Using FrankenPHP

• Built-in HTTP/3 support
• Native PHP integration, which reduces latency and resource overhead
• Reduced resource consumption by eliminating the need for FastCGI
• Simplified deployment with features from Caddy, like auto-HTTPS
• Laravel octane support
• Native support for HTTP 103 Early Hints with potential to improve page load by 30%

Cons of Using FrankenPHP

• Worker mode can introduce complexity (part of the learning curve)
• Older and/or complex applications might run into compatibility issues, especially when trying to leverage worker mode
• Being relatively new, it’s not battle-tested, and there’s potential for instability

RoadRunner

As the name implies, RoadRunner is a PHP application server focused on high performance. Like FrankenPHP, it is written in Go, but that’s pretty much where the similarities end. RoadRunner keeps PHP applications in memory and utilizes Go’s concurrency model (goroutines) to manage PHP processes. This eliminates the need for frequent bootstrapping and reduces latency.

Use Cases for RoadRunner

For applications that have long-running processes, RoadRunner is a good option due to its ability to handle these long-running processes without the need to constantly reload, reducing overhead and improving performance. RoadRunner also has Centrifuge, which enables websocket communication, making it a great option for applications that need real-time communication.

Pros of Using RoadRunner

• Persistent worker pool
• Low memory usage
• High performance
• Built-in load balancer and process manager
• Extensions can be written in Go

Cons of Using RoadRunner

• HTTP/3 support is currently only “experimental”
• Debugging can be complex due to persistent worker model
• Existing code may need to be adapted, especially any source that relies on the typical request-response lifecycle

OpenSwoole

OpenSwoole is a very intriguing PHP extension which enables the application server to be written in PHP and built into the application, similar to Node.js. Also like Node.js, OpenSwoole enables asynchronous, parallel, and coroutine-based programming. This makes OpenSwoole ideal for high-performance applications like microservices, task queues, and even a dedicated PHP-based web server. Combined with websockets and real-time communication, OpenSwoole is also great for writing chat applications, online gaming, streaming platforms, and live dashboards.

Use Cases for OpenSwoole

OpenSwoole is an even better option for those applications that rely heavily on real-time communication, as WebSockets are at the core of its design. Chat applications, online gaming, or live data platforms can all benefit from OpenSwoole’s asynchronous and coroutine model and its ability for real-time communication.

Pros of Using OpenSwoole

• Extremely high performance
• Little overhead
• Efficient resource utilization
• Built-in async capabilities
• Support for websockets and coroutines

Cons of Using OpenSwoole

• Even steeper learning curve due to differences in asynchronous patterns vs traditional PHP’s synchronous patterns
• Not ideal for migrating existing applications due to compatibility issues
• State management is more complex
• Since OpenSwoole runs as a long-running process, the service may need to be restarted between code changes for the changes to be reflected

Limitations of PHP App Servers

While PHP application servers offer powerful performance for certain use cases, they also introduce new architectural challenges. Unlike traditional stateless PHP setups, these servers rely on long-lived processes, shared memory, and persistent workers — making them harder to scale, maintain, and upgrade.

Horizontal Scalability

Traditional PHP is stateless in that every request starts a new and individual PHP process. This makes horizontal scaling easy by spinning up more servers behind a load balancer. In contrast, these PHP application servers maintain long-lived workers, shared objects, in-memory cahes, and other stateful artifacts. 

This state is not shared across server instances, so spinning up more instances doesn’t share this memory state. To solve this problem, you’d need to introduce an external storage layer like Redis to synchronize the PHP application server state across instances, adding another layer of complexity.

OpenSwoole and RoadRunner introduce even more problems by using worker pools or coroutines to handle concurrency, and these are isolated per instance. Spinning up more app server instances would require external coordination to balance traffic and workloads.

Maintenance Costs

PHP application servers require a different level of expertise than traditional PHP applications. The ecosystem for these is small. You’re not going to find very many StackOverflow answers or community examples.

They also require more complex deployment and orchestration than traditional PHP applications. While traditional PHP servers are well supported across nearly all hosting platforms, these all-in-one application servers are typically roll-your-own, and you will be in charge of getting it up and running from scratch and without support. Testing and debugging are also much harder. Bugs become non-deterministic with one request affecting another. Bugs are difficult to replicate locally. Stack traces may not clearly identify coroutine boundaries.

Memory leaks are almost unheard of in traditional PHP applications, but the long-lived processes in these PHP application servers introduce that risk with much higher frequency. Frameworks can easily leak memory, due to their nature and assumption they’re running stateless, if not properly reset. In other words, you must manually reset or isolate state between requests. This requires intimate knowledge of the framework you’re using to fix leaks and a higher burden on monitoring to ensure leaks aren’t happening.

Complex Upgrades

Upgrading traditional PHP applications is fairly straightforward. Sure, it may require a lot of work when it comes to ensuring your source code is compatible with a newer PHP version, but the execution and deployment of the upgrade is straightforward. Each request starts fresh with a new process. There’s no shared memory or lingering objects between requests, no state management, and nothing to consider when switching environments. This makes it simple to flip the switch with a big-bang upgrade or slow rollout with canary or blue/green deployment strategies.

In contrast, upgrading a PHP application built in an all-in-one server is relatively complex, and there’s a lot more to consider. The PHP application lives in memory and its objects, configurations, service container, and static properties persist. You must ensure the old state is cleared. You’ll need to reload and restart workers gracefully in hopes you don’t disrupt end users. It’s stateful, and this makes slow rollout deployment strategies more complex or nearly impossible without a lot of consideration and setup. Even then, there is still a risk that the upgrade strategy will fail.

Unlike traditional PHP applications, you can’t just deploy new code. You must orchestrate worker reloads. 

ZendPHP: An Enterprise-Grade Alternative to PHP Application Servers

ZendPHP is a fork of the PHP community edition that comes with backported security patches and enterprise level support. Regarding its runtime, it’s the same as the community edition. This means that you’ll find endless documentation, implementation examples, and community answers to your questions all over the internet.

Unlike these all-in-one application servers, ZendPHP follows the traditional shared-nothing model with individual PHP processes starting per individual request, just like the community edition. You can utilize the battle-tested, mature serving patterns like Apache’s mod_php and Nginx with PHP-FPM. You can rest assured that your application(s) will be stable, and configurations and scalability will be straightforward and simple. In addition, ZendPHP is a one-for-one drop-in replacement for the community edition.

On-Demand Webinar: Secure, Scale, and Optimize With ZendPHP

ZendPHP runtimes offer a reliable, and high-performance environment for mission-critical applications. ZendHQ, an extension for ZendPHP, provides plug-and-play tools to monitor, manage, and tune app performance – integrating seamlessly with your existing APMs. Learn more in this on-demand webinar.

PHP Application Servers vs. ZendPHP: At-A-Glance Comparison

Use this table as a quick-reference comparison of ZendPHP and PHP application servers, including execution models, performance, and more.