Kingsfordweg 151, 1043GR Amsterdam, The Netherlands ● 24/7 support — support@novogara.com
Knowledge base

nginx, Apache or Caddy

All three will serve your site. They differ in how they behave when things get busy, and in how much configuration you have to write to get there.

nginx

Event-driven, so thousands of idle connections cost almost nothing. Excellent as a reverse proxy, a static file server and a TLS terminator. Configuration is explicit and a little unforgiving — location matching in particular catches people out — but it does exactly what you wrote.

The default choice for a machine serving an application behind it, and what we run ourselves.

Apache

Still the most flexible. The module ecosystem is unmatched, and .htaccess lets you delegate configuration to a directory, which is exactly what shared hosting and many control panels need. With the event MPM it handles concurrency far better than its reputation suggests.

Choose it when you need per-directory configuration, when an application expects it, or when your control panel has already chosen it for you.

Caddy

Obtains and renews TLS certificates by itself, with no certbot and no cron. The configuration file is short enough to read in one go. The trade is a smaller ecosystem and fewer people who can help when something unusual breaks.

Very good for a straightforward site or a small set of services where you would rather not think about certificates at all.

What matters more than the choice

  • Caching. A correctly set Cache-Control on static assets removes more load than any amount of tuning.
  • Compression. gzip everywhere, brotli where you can. Text responses shrink by two thirds.
  • HTTP/2, and HTTP/3 if your traffic is mobile-heavy.
  • Timeouts and body limits. The defaults are generous; a slow client that holds a connection open for an hour should not be able to.
  • Rate limiting on login and form endpoints. See firewalling for the layer below it.
  • Logging. Know what you are writing, and rotate it — see log management.

A reverse proxy in front is usually right

Whatever runs your application — PHP-FPM, Node, Python, Go — put a web server in front of it. It terminates TLS, serves static files without waking your runtime, buffers slow clients, and lets you deploy a new version behind it without dropping connections. Even a single-binary Go service benefits.

See PHP-FPM tuning and running your application as a service.

Check what you changed

Both nginx and Apache will tell you whether a configuration is valid before you apply it. Make it a habit:

nginx -t && systemctl reload nginx

apachectl configtest && systemctl reload apache2

Reload, not restart: existing connections are finished rather than cut. And after a reload, give the old workers a moment before concluding that your change did not work — they serve requests until they drain.


Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base