Choosing the Right PHP Stack

A PHP stack refers to the operating system, web server, PHP, and anything PHP consumes or interacts with. This includes databases, queues, caches, APIs, and more. Additionally, your PHP stack requirements will differ depending on if you’re in development or production. This means that when building your stack, you must account for the needs of your application while staying aligned with where that application is within its lifecycle.

To help you get started, this guide gives a high-level view of the PHP stack selection process, broken down by the stages of the application lifecycle. Along the way, I touch on popular PHP stacks, and I explore the role of containers, virtual machines, and Platform as a Service.

PHP Stacks: Considerations by Environment

The best PHP stack for your applications will depend on your environment. Requirements vary depending on if the application is in development or production, with each bringing unique priorities. Check out this table for a quick-reference comparison and read more in-depth explanations below.

PHP Stack Considerations for Development

In development, you must consider how close you want the environment to be to the production environment. For many, the answer will be “close enough,” with tools like database abstraction, tests for PHP combability, and web server definition meaning you don’t need an exact environment. You only need the application to run. However, keeping the development and production environments as close as possible is generally a good idea, and we have tools such as virtual machines (VM) and containers to assist us.

For most developer teams, the main question will be if you want to run everything directly on your machine natively, or do you want to launch it on demand, using VM and/or containers? When talking about running services natively, we're talking about launching the various services (web server, PHP, database) directly on your machine. If you're only ever developing on a single application, this can be rather convenient, as you can have everything setup and working all the time.

Running native services is particularly interesting when in early development stages, when you may need to tinker heavily with database schemas, web server configuration, and PHP configuration, and want to make changes on the fly. The downside is that when you don't need those services running, they're eating up resources. Additionally, if you need to work on more than one project, you'll find yourself needing to automate configuration changes when you switch between them.

PHP Stack Considerations for Production

Production PHP stacks have a number of concerns that you may not consider during development. 

For instance, in production, needs may change based on how you want to deploy and manage the stack. Will you be deploying on-premises and self-managing? If so, how will you split services for redundancy and/or scaling? Or will you be using a cloud vendor? Will you be using cloud images? Which operating systems are available? How will you split capabilities and responsibilities between machines? If you choose to go with containers, you will need to consider the fact that you may want leaner images with reduced OS capabilities for security, performance, and scaling.

Additionally, unlike development, you will want to run a service per machine, both for security and scalability. Your database will require redundancy, meaning a minimum of a primary and a secondary node. For performance reasons, you will want to route write requests to the primary node, and route read requests to secondary nodes; read operations are cheap, and having multiple read-only nodes ensures that the most common database operations run the most quickly and consume the fewest resources.

Similarly, cache services such as Redis can be run in clusters, and will require fewer servers with different capabilities than your web servers. Your web servers should operate idempotently but may need to allow sharing state (sessions!) between instances — a scenario often called "session clustering.”

Types of PHP Stacks

When building or deploying PHP applications, your choice of stack determines everything from performance and scalability to ease of development. While the traditional LAMP stack remains the most recognized option, modern workflows have introduced variations and alternatives that cater to different environments and needs. From lightweight local development stacks like XAMPP, WAMP, and MAMP to cloud-ready solutions leveraging containers and virtual machines, each approach offers unique benefits and trade-offs.

Traditional LAMP Stack

Broadly speaking, most PHP stacks are a LAMP stack. While LAMP stands for Linux, Apache, MySQL/MariaDB, and PHP, it does have a wide range of variations.

While Linux is the kernel, there's a plethora of distributions to choose from, such as Ubuntu, Debian, and others. Until recent years, Apache was the most commonly used web server, but today, nginx competes neck and neck with it, leading to variants such as LEMP (the "E" stands for nginx in this case) — but more on LEMP stacks below. 

MySQL and MariaDB are the most commonly used databases with PHP, but you can pick and choose the one that best suits your needs. Common choices include PostgreSQL (for OSS enthusiasts or organizations that could benefit from its strong extension system), and MS SQL Server, Oracle, and DB2 (commercial databases common in larger organizations).

 The PHP stack itself may be — and generally is — multiple machines, with a cluster of database nodes, a cluster of caching nodes, a cluster of queue nodes, and a cluster of web servers. In fact, PHP itself does not need to run on the same server as the web server! You can have multiple PHP-FPM servers sitting behind one or more web servers that act as reverse proxies.

Pros and Cons of LAMP Stacks

LEMP Stack

As mentioned above, the LEMP stack is a modern variation of the traditional LAMP stack, with Apache replaced by nginx, which makes it more suited to performing under heavy loads due to nginx’s event-driven architecture.

Like LAMP stacks, a LEMP stack can scale horizontally, with clusters for databases, caching, queues, and multiple PHP-FPM servers proxied behind nginx. This flexibility allows developers to build cloud-ready environments without sacrificing speed or reliability.

Pros and Cons of LEMP Stacks

XAMPP, WAMP, and MAMP Stacks

The most popular native PHP development stacks are XAMPP, WAMP, and MAMP.

XAMPP is one of the oldest, most-used PHP development environments. XAMPP stands for "Cross-operating system Apache, MySQL/MariaDB, PHP, and Perl" and provides each of these components out of the box. It includes a control panel, and users can add plugins for popular PHP applications and tools. Finally, it can be used on each of Linux, Windows, or Mac OSX.

WAMP stands for "Windows, Apache, MySQL, and PHP" and provides Apache2, PHP, and MySQL configured on Windows. PHPMyAdmin is used by default, but there are no additional plugins available.

MAMP stands for "Mac OSX, Apache, Mysql, and PHP." Interestingly, it also supports nginx, Python, Perl, and Ruby, and can run on Windows. A paid version, MAMP PRO, allows installation of plugins, such as WordPress, Joomla, or Drupal. MAMP stacks provide the ability to run multiple hosts across multiple versions of PHP, solving some of the issues developers run up against when developing multiple PHP applications.

Virtual Machines and Containers

If you're developing multiple applications, or if your role involves other duties, you may want to instead spin up the services needed by the application only when you're actively developing. 

VMs and containers give you this flexibility and allow each project to strictly define their exact needs. In both cases, you can get closer to precisely emulating your production environment, as the VMs or containers can exactly mimic the production services, down to the operating system.

Virtual Machines

Virtual machines run in emulation environments and allow booting arbitrary operating systems. They are often the basis for production environments and are roughly equivalent to cloud machine images found in Infrastructure as a Service (IaaS) platforms such as AWS and Azure.

Virtual machines can thus run any services available to the operating system they run, allowing you to run web servers, database servers, and more. You can also run several VMs in parallel, and network them, allowing you recreate your production environment locally. 

When it comes to virtual machines, Vagrant is your friend, as it gives you the ability to describe the full set of services you need, and launch them, either in a single VM or as a cluster of VMs, often using code in your working directory as the basis for the services.

Container Images

With Docker, you can spin up a single image, or use docker-compose to spin up a cluster of networked images. Each image describes a machine running a specific operating system, and, ideally, a single service it will expose, such as a web server, php-fpm pool, database, cache, etc. 

These run in a sandbox on the host system, utilizing a portion of its resources, and often sharing libraries and binaries, allowing them to run more quickly and with fewer resources than virtual machines. They often take seconds or less to start, and consume minute amounts of memory, versus the several minutes and large amounts of memory required by VMs (which need to allocate all required memory, even when not in use).

While you can run any operating system via a container, generally speaking, you want to keep the container as small as possible so it can spin up quickly. This is particularly important if you think you will be doing autoscaling, as it allows you to react quickly to traffic. As such, the operating systems in containers are often very barebones, providing only the minimum tooling necessary to launch common daemons and services. In development, you will generally use docker-compose, allowing you to orchestrate a full suite of services representing your entire production stack, and spin them up and down as needed.

Platform as a Service for PHP

Implementing your PHP application architecture can be overwhelming. You may know you need caching, a relational database, and queue workers, but how do you actually manage them, much less create a redundant pool of them? For instance, with queue workers, you will likely need infrastructure to loop through the queue and run jobs, as well as something to monitor them and ensure they don’t go down — or are restarted when they inevitably fail. Database clustering often takes specialized training to setup and operate.

Platform as a Service (PaaS) offerings exist to offload this complexity. Instead of setting it up yourself, you describe your infrastructure and scaling requirements, and supply your application, and the PaaS takes care of the orchestration. They generally also provide ways to monitor your application, and self-healing factors (in case elements of the infrastructure fail). 

Key Benefits of PaaS for PHP

The key benefit a PaaS for PHP provides is exactly that: a simplified way to describe your application infrastructure and how the various services interact, without the overhead of actually implementing it yourself or maintaining it long-term. 

Many PaaS solutions come with “push-to-deploy" capabilities as well — push changes to a specific version control branch or repository in order to trigger a deployment — and generally include a corresponding rollback functionality. These features can help reduce operational risk, particularly in organizations that may not have a stable of DevOps experts to lean on.

Disadvantages of PaaS for PHP

Of course, you can’t expect these benefits to come without a price! For small deployments, a PaaS for PHP can often look like a great deal, but as the size and complexity of your deployment increases, your bill for the service will grow accordingly and often exponentially. 

Another issue presented by a PaaS is that they make spinning up development and CI/CD deployments more difficult. Your team will become versed in how to describe the deployment in the PaaS’s custom configuration, but this will not map to available OSS tooling, leaving your developers and QA team to recreate, often incompletely, the production environment using other technologies. The other downside to this is that if you determine at any point that you need to move off the service ­— for cost, compliance, or other reasons — your migration effort will be more complex, as you’re now forced to recreate the infrastructure yourself.

A PaaS also generally has limited options: you can choose only from the databases they support, the caching services they integrate with, even the specific cloud provider they utilize. This can sometimes mean choosing a technology that isn’t suited well for your application, or omitting a feature that cannot be accommodated by their offering.

Final Thoughts

Choosing the right PHP stack can be a daunting task. You're tasked with ensuring everything is secure, scalable, and efficient, all while juggling compatibility across environments, managing resource constraints, and meeting compliance standards. It can be difficult to balance all these considerations while also focusing on other business goals.

The Zend Enterprise Web Platform is designed with developer teams like yours in mind. It simplifies the complexity of managing PHP applications by combining the ease of PaaS with the control of self-managed environments. With secure PHP runtimes, CIS-hardened images, autoscaling, and real-time observability, the platform gives you the tools you need without hidden costs or management headaches.

Let Zend and the Enterprise Web Platform take on the heavy lifting while you focus on what matters most: building high-quality, mission-critical applications.

Additional Resources

• Guide - Developing Web Applications With PHP
• Blog - PHP Monolith to Microservices: When to Split Web Applications
• Blog - PHP Dependency Management Using Composer
• Blog - Guide to Enterprise Web App Development
• Blog - How to Secure PHP : Best Practices for Developer Teams