Apache vs. NGINX vs. Caddy: Web Servers Explained

Howdy Friends! Every website you visit is served by a web server — software that listens for incoming requests and responds with the right content. Three names dominate this space: Apache, NGINX, and Caddy. They all do the same fundamental job, but they approach it very differently. Let’s dig in.

What Does a Web Server Actually Do?

When a visitor types your URL and hits enter, their browser sends an HTTP request to your server. The web server receives that request, figures out what to return — a webpage, an image, a file — and sends it back. It also handles HTTPS encryption, redirects, virtual hosting (serving multiple domains from one server), and proxying requests to backend applications like PHP or Node.js.

That’s the job. How each server handles that job under the hood is where the differences get interesting.

Apache

Apache HTTP Server has been around since 1995 and was for a long time the most widely used web server on the internet. It’s mature, extensively documented, and supported by virtually every hosting control panel and Linux distribution out of the box.

How Apache Handles Requests

Apache uses a process-based or thread-based model depending on which Multi-Processing Module (MPM) is configured.

• Prefork MPM — Apache spawns a pool of worker processes ahead of time. Each process handles one connection at a time. Simple and stable, but memory-hungry.
• Worker MPM — Uses threads instead of processes. Each process spawns multiple threads, each handling one connection. More efficient than Prefork.
• Event MPM — The most modern option. Improves on Worker by handling keep-alive connections more efficiently, freeing threads to serve new requests while waiting on idle connections.

Under load, even with Event MPM, Apache can struggle with very high concurrency because each active connection still ties up a thread.

Configuration

Apache’s configuration system is powerful and flexible — sometimes to a fault. Configuration lives in httpd.conf and a hierarchy of included files. One of Apache’s most distinctive features is .htaccess — per-directory configuration files that can override server settings at the directory level without restarting the server.

.htaccess is powerful for shared hosting environments where individual users need control over their own directories. It comes at a performance cost, though — Apache has to check for .htaccess files on every request, all the way up the directory tree.

Where Apache Is Good

• Legacy applications and shared hosting environments
• Situations where .htaccess support is required
• Environments where broad compatibility and documentation matter most

NGINX

NGINX (pronounced “engine-x”) was released in 2004, designed from the ground up to solve a specific problem: handling tens of thousands of simultaneous connections without consuming enormous amounts of memory. It succeeded.

How NGINX Handles Requests

NGINX uses an event-driven, asynchronous, non-blocking architecture. This is fundamentally different from Apache’s thread-per-connection model.

NGINX runs a small, fixed number of worker processes — typically one per CPU core. Each worker runs an event loop that can handle thousands of connections simultaneously without spawning new threads or processes. When a connection is idle or waiting on I/O, the worker moves on to the next connection rather than sitting idle.

The result is dramatically lower memory usage and much better performance under high concurrency compared to Apache’s traditional models.

NGINX does not execute application code directly. For PHP, it passes requests to PHP-FPM (FastCGI Process Manager) via FastCGI. For Node.js, Python, or other app servers, it proxies requests upstream. This separation keeps NGINX lean — it handles what it’s good at (connection management, static files, TLS) and hands off the rest.

Configuration

NGINX configuration is declarative and hierarchical. The main config file (nginx.conf) uses a block-based structure with http, server, and location blocks. It’s clean and readable once you understand the structure, but it can be unintuitive at first — especially directives that behave differently depending on where they appear in the hierarchy.

NGINX does not support .htaccess. All configuration must be in the server-level config files and requires a reload to take effect.

Where NGINX Is Good

• High-traffic sites and applications
• Reverse proxy and load balancing
• Static file serving at scale
• Environments where memory efficiency matters

Caddy

Caddy is the newest of the three, with its first stable release in 2015 and version 2 launching in 2020. It was built with modern web standards and developer experience as first-class priorities — and it shows.

How Caddy Handles Requests

Like NGINX, Caddy uses an event-driven, non-blocking model. It handles concurrency efficiently without the overhead of a thread-per-connection approach. Performance is comparable to NGINX for most workloads.

Where Caddy truly differentiates itself is in what it does automatically.

Automatic HTTPS

Caddy handles TLS entirely on its own. Point a domain at your server, add it to your Caddyfile, and Caddy automatically obtains a certificate from Let’s Encrypt (or ZeroSSL), configures HTTPS, and handles renewals — with zero manual intervention. No Certbot, no cron jobs, no cert expiry surprises.

Caddy also defaults to the most current TLS best practices out of the box: TLS 1.2 minimum, strong cipher suites, HSTS headers. You have to deliberately opt out of good security rather than opt in.

Configuration

Caddy’s configuration file is called the Caddyfile. It’s remarkably readable compared to Apache or NGINX config.

A basic HTTPS reverse proxy in Caddy:

example.com {
    reverse_proxy localhost:3000
}

That’s it. Caddy handles the certificate, the redirect from HTTP to HTTPS, and the proxy. The equivalent NGINX configuration with manual Certbot setup is significantly longer.

Caddy also supports a JSON-based API for dynamic configuration — you can update routes, add sites, and change settings at runtime without restarting the server. This makes it well-suited for environments that need to reconfigure on the fly.

Resource Footprint

Caddy is written in Go. It’s a single binary with no external dependencies. Memory usage is lean. Startup is fast. There are no modules to compile in or external libraries to manage.

Where Caddy Is Good

• Modern stacks where automatic HTTPS is a priority
• Reverse proxy setups with clean, readable config
• Environments where developer experience and maintainability matter
• Containerized deployments where a single binary is ideal

Side-by-Side Comparison

Why GR Host Uses Caddy

We evaluated all three and landed on Caddy for every GR Host server — and we haven’t looked back.

The automatic HTTPS is the obvious win. Every customer site gets a valid certificate from day one with zero configuration on their part. Renewals are handled automatically. Certificate expiry is simply not a thing our customers have to think about.

The Caddyfile is genuinely a pleasure to work with compared to the alternatives. Config is readable, concise, and easy to audit. When we need to add a new site, update a proxy rule, or change a redirect, it’s fast. Less config complexity means fewer mistakes and easier maintenance across our fleet of servers.

Caddy’s resource footprint is lean, which matters on VMs where every MB of RAM serves a customer’s workload rather than the web server itself. And the single-binary deployment fits cleanly into our containerized Podman-based stack.

Apache and NGINX are excellent servers with long track records. For certain use cases — legacy applications, shared hosting, high-traffic reverse proxies at scale — they’re the right tool. For the way GR Host builds and manages infrastructure, Caddy is the right tool for us.

Questions about your hosting setup or how we configure things under the hood? Get in touch — we’re always happy to talk shop.

• 2026 11
• 2025 7
• 2024 6
• 2023 2