Ask "Nginx or Apache?" in a room full of PHP developers and you'll get strong opinions in both directions. Most of them were formed around 2010, when the answer really did matter a lot.

Here's my slightly unpopular take: for a modern PHP app running on PHP-FPM, the web server is rarely what makes your app slow. But the two servers do behave differently, and a couple of those differences will bite you if you move from one to the other without knowing them.

Where the reputation came from

The classic Apache setup used mod_php: PHP lived inside every Apache process. That forced the prefork model, one process per connection, each one carrying a full PHP interpreter. Serving a tiny CSS file? That's a heavy PHP-loaded process tied up for it. Slow clients on mobile networks? Each one holds a fat process hostage until it finishes.

Nginx was built differently from day one. A few worker processes run an event loop, each juggling thousands of connections at once. It never runs PHP itself. It hands PHP requests to a separate pool of PHP processes over FastCGI.

Under heavy concurrent load, that difference was dramatic, and Nginx earned its reputation honestly.

What changed: PHP-FPM everywhere

Modern Apache doesn't have to work like that. With the event MPM and mod_proxy_fcgi, Apache also hands PHP off to PHP-FPM, exactly like Nginx does. Static files and idle keep-alive connections no longer occupy a PHP process.

Once both servers sit in front of the same PHP-FPM pool, your PHP code runs in the same processes, with the same OPcache, at the same speed. The request that takes 400 ms because of a missing index takes 400 ms behind either one.

The real differences, side by side

The .htaccess question

.htaccess is Apache's best and worst feature. Best, because you can drop a file in a folder and change rewrites, redirects or headers without touching server config or restarting anything. That's why shared hosting loves it, and why Laravel ships a public/.htaccess that just works.

Worst, because when AllowOverride is on, Apache checks for .htaccess files in the requested directory and every parent, on every request. And config scattered across random folders is hard to review.

If you control the server, put the rules in the virtual host and set AllowOverride None. You get the speed back and the config in one place.

And the gotcha when you migrate: Nginx ignores .htaccess completely. Every rewrite, redirect, deny rule and header in there has to be translated by hand. Forget one that blocks access to a sensitive folder, and it's silently open after the move.

What a Laravel site needs on Nginx

The core of it is short. This is close to the example in the Laravel deployment docs (simplified, without TLS):

server {
    listen 80;
    server_name example.com;
    root /var/www/app/public;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ ^/index\.php(/|$) {
        fastcgi_pass unix:/var/run/php/php8.4-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_hide_header X-Powered-By;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

Two details worth understanding rather than copying:

• try_files does the job of Laravel's .htaccess: serve the file if it exists, otherwise send the request to index.php.
• Only index.php is passed to PHP. A generic location ~ \.php$ block would execute any PHP file it finds under public/, including one an attacker managed to upload. Narrow is safer.

The full reference is in the Laravel deployment docs.

So which should you use?

It depends on three things, and here's where I land on each:

• Who controls the server? On shared hosting you get Apache and .htaccess, end of discussion. On your own VPS or cloud server, I reach for Nginx + PHP-FPM.
• What else is it doing? If the same box also proxies to a Node service, terminates TLS for several apps or serves lots of static assets, Nginx's reverse proxy config is clean and light.
• What does the team know? A well-configured Apache beats a copy-pasted Nginx config nobody understands. Familiarity is a valid reason.

Locally I'm happy on XAMPP's Apache, and in production I prefer Nginx in front of PHP-FPM. That combination works fine as long as you remember the .htaccess rules don't travel.

Checklist before you switch

1. Move to PHP-FPM first. That's where most of the gain is, on either server.
2. List every .htaccess file in the project and translate each rule.
3. Pass only your front controller to PHP.
4. Deny dotfiles (except .well-known), and keep .env outside the web root anyway.
5. Load test before and after, so the decision is based on your app, not on a forum thread.

Which one runs your PHP apps today, and was it a deliberate choice or just what the server came with?