LAMP, LEMP, or Nginx + Apache: which web stack to choose

LAMP and LEMP are two classic stacks for PHP sites: Linux, a web server, a database, and PHP. They differ by the web server: LAMP uses Apache, LEMP uses Nginx. In practice the more important difference is how the web server runs PHP. That affects memory usage, behavior under load, and whether you need a second web server.

What the stack consists of

Instead of MySQL you can use PostgreSQL in both stacks — most modern PHP applications support it. The stack name doesn’t change because of that.

How Apache runs PHP

Apache has two ways to run PHP.

mod_php. The PHP interpreter is embedded directly into Apache processes. This is the simplest option, but it doesn’t work well with Apache’s multithreaded models. Third-party PHP extensions are not always thread-safe, so mod_php is typically used with the prefork MPM. According to Apache documentation, prefork is “a non-threaded, pre-forking web server”, and it’s suitable for sites that need to avoid threads because of libraries that aren’t designed for multithreading. Each process handles a single connection, so with a hundred concurrent visitors you need a hundred processes, and each contains a full PHP interpreter, even if an image was requested.

PHP-FPM. PHP runs as a separate service with its own pool of processes, and Apache hands requests to it via the mod_proxy_fcgi module. In that case Apache can use the event MPM: according to the documentation, after sending a response a worker thread hands the connection to a separate listener thread, and idle keep-alive connections do not occupy worker threads. Apache serves static files itself without touching PHP.

Minimal Apache + PHP-FPM via a socket:

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost/"
</FilesMatch>

The socket path depends on the PHP version and the distribution. The main takeaway: the statement “Apache creates a process per request” is true only for prefork. Apache with event and PHP-FPM is architecturally similar to Nginx with PHP-FPM.

How Nginx runs PHP

Nginx cannot execute PHP itself — there is no built-in module. It always forwards PHP requests to PHP-FPM over FastCGI, and serves static files directly. Minimal configuration:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

The file snippets/fastcgi-php.conf is present in Debian and Ubuntu packages; in other distributions the necessary FastCGI parameters are set manually.

The main practical difference — .htaccess

Apache reads .htaccess files in site directories: they contain redirect rules, directory protection, caching settings. Many CMSs, primarily WordPress and Bitrix, rely on this mechanism and write their rules to .htaccess. Nginx does not read .htaccess: everything is defined in the server configuration, and after changes it needs to be reloaded.

For the administrator this is a plus — configuration is in one place and not checked on every request. For the owner of a site running a ready-made CMS this can be a problem: rules from .htaccess will need to be migrated into Nginx configuration manually, and when plugins are updated you must watch that nothing gets lost.

Hybrid: Nginx in front of Apache

In a hybrid setup Nginx accepts connections on ports 80 and 443, terminates HTTPS, serves static files itself and forwards the remaining requests to Apache, which listens on an internal port, for example 127.0.0.1:8080. The site continues to use .htaccess.

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

On the Apache side you need the mod_remoteip module so that the real visitor address is visible in logs and in the application, instead of 127.0.0.1. The application must understand the X-Forwarded-Proto header, otherwise when HTTPS is terminated it may go into an infinite redirect to HTTPS.

This scheme is used by many hosting control panels by default. Read more about reverse proxying with Nginx and how to choose between Nginx, Apache, HAProxy, Caddy and Traefik in the article “Caddy vs. Traefik vs. HAProxy vs. Nginx vs. Apache”.

When to choose what

A hybrid is justified when .htaccess is needed. If the site doesn’t depend on it, a second web server is extra memory, an extra layer where configuration can break, and an extra package to keep updated.

Common mistakes

• mod_php with the event MPM. Debian and Ubuntu packages switch Apache to prefork when libapache2-mod-php is installed. If you later enable event manually, Apache may refuse to start or work unreliably. With event use PHP-FPM.
• MaxRequestWorkers not set according to memory. In prefork each process uses tens of megabytes. Apache documentation explicitly says: the value should be large enough for expected load and small enough so that all processes fit in available RAM. Otherwise the server will start swapping.
• Apache in hybrid listening on an external interface. Port 8080 should be accessible only from 127.0.0.1, otherwise the site can be accessed bypassing Nginx.
• Different PHP versions in pools. Each PHP-FPM version has its own socket; check that the web server points to the correct one.
• Static files via PHP. If all requests, including images, go to PHP-FPM, the server wastes resources. Rules for serving static files should come before the PHP rule.