Nginx vs Apache vs Caddy: How to Choose a Web Server in 2026

The old Nginx vs Apache vs Caddy debate usually starts with benchmark charts. In 2026, that is the wrong place to start.

The CA/Browser Forum approved Ballot SC-081v3, which sets a schedule for reducing public TLS certificate maximum validity periods. The ballot describes a reduction that starts in March 2026 and ends in March 2029 at 47 days. DigiCert’s explainer gives the operational dates in plain form: 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029.

Once certificate lifetimes keep shrinking, the choice gets less theoretical. Performance and architecture still matter. The first operational question is simpler: how much certificate, TLS, reload, and protocol work do you want humans to keep doing?

Manual certificate management is finished as a serious plan. You can renew a 47-day certificate by hand in theory, the same way you can run production backups by dragging files into a folder. The failure mode is obvious, and it will arrive at the worst time.

All version-sensitive claims below were checked on July 2, 2026. HTTP/3 and ACME support are still moving enough that dates matter.

The short answer

Caddy is the low-ops choice. It gives you automatic HTTPS, sensible TLS defaults, and HTTP/3. For a small team, a product site, a dashboard, or a containerized service, Caddy usually gets you to the right end state fastest.

Nginx is the control choice. It has the highest ceiling for reverse proxying, load balancing, traffic shaping, and careful tuning. Native ACME closes the old certificate gap, but Nginx still expects you to understand the config model. Fair trade, if you want the control.

Apache is the compatibility choice. Pick it for .htaccess, legacy modules, shared-hosting compatibility, or old WordPress and PHP workflows that expect per-directory overrides. If HTTP/3 matters now, Apache is the weak fit here.

Architecture decides the memory curve

Apache 2.4 is built around Multi-Processing Modules. The official Apache MPM documentation explains that Apache can use prefork, worker, or event, with only one MPM loaded at a time. prefork is process based, worker mixes processes and threads, and event is the modern default on most Unix-like systems.

Apache’s flexibility is useful, but it spreads the work around. You are choosing a process model, module set, virtual host structure, override behavior, and usually a PHP execution model.

Nginx uses a master process and worker processes. Its beginner guide says worker processes handle requests and that Nginx uses an event-based model with OS-dependent mechanisms to distribute work efficiently. That keeps connection handling cheap when the server is mostly moving bytes between clients and upstreams.

Caddy 2 is written in Go. The Caddy architecture docs describe it as a single static binary with zero external dependencies, and Caddy’s HTTP stack sits on Go’s concurrency model. Deployment is simple. Concurrency is good. Under extreme reverse-proxy load, Go runtime behavior, garbage collection, and fewer low-level tuning knobs can matter.

For a reverse proxy pushing very high concurrency and strict tail-latency targets, Nginx still has the sharper toolset.

HTTP/3 status in 2026

HTTP/3 runs over QUIC and UDP. Enabling it means the server must listen on UDP 443, the firewall must allow it, and the network path must pass QUIC cleanly.

Nginx has HTTP/3 support through ngx_http_v3_module. The current official docs say the module was introduced in 1.25.0 and still describe it as experimental support. That label is not a panic button. It is a reason to test your clients, CDN, firewall, kernel, and observability stack before you call the rollout done.

Caddy supports HTTP/3 by default. Its global options documentation lists the default HTTP protocols as h1 h2 h3, and automatic HTTPS is part of the normal site-address flow.

Apache is behind here. Apache’s public 2.4 module index lists mod_http2 for HTTP/2 and mod_proxy_http2 for proxying HTTP/2, but no HTTP/3 module. The mod_http2 page describes support for the HTTP/2 transport layer. As of July 2, 2026, Apache is a poor choice if HTTP/3 is a near-term requirement.

Certificate automation is the main event

The certificate lifetime schedule turns ACME from a nice-to-have into infrastructure. If renewals are boring and visible, 47-day certificates are manageable. If renewals depend on a wiki page and a tired person on a Friday, the system is already broken.

Caddy wins this section by design. Its automatic HTTPS docs say Caddy serves public DNS names over HTTPS using certificates from public ACME CAs such as Let’s Encrypt or ZeroSSL, keeps managed certificates renewed, and redirects HTTP to HTTPS automatically. If Caddy knows the public site name, it serves the site over HTTPS automatically. Issuance, renewal, redirects, OCSP behavior, and protocol defaults are part of the normal path.

Nginx caught up in 2025. It announced a preview release of ngx_http_acme_module on August 12, 2025. The announcement says the module provides directives for requesting, installing, and renewing certificates from Nginx configuration, and that it is a Rust-based dynamic module for both Nginx Open Source and NGINX One customers using NGINX Plus. The current module docs say ngx_http_acme_module implements ACMEv2, its source is on GitHub, and a prebuilt nginx-module-acme package exists since 1.29.0. N.WTF’s Debian and Ubuntu builds include the official module by default; its changelog records nginx-acme being added on November 29, 2025. Let’s Encrypt also covered the official module.

A practical Nginx ACME baseline starts with a persistent state directory. The module stores account data, certificates, and private keys there, so create it before reload and keep its permissions tight:

sudo mkdir -p /var/cache/nginx/letsencrypt

The Nginx configuration is longer than Caddy’s, but it now keeps ACME, HTTP/2, and HTTP/3 inside Nginx:

resolver 8.8.8.8:53 ipv6=off valid=5s;

acme_issuer letsencrypt {
    uri         https://acme-v02.api.letsencrypt.org/directory;
    contact     [email protected];
    state_path  /var/cache/nginx/letsencrypt;
    accept_terms_of_service;
    ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
}

acme_shared_zone zone=ngx_acme_shared:1M;

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;

    location /.well-known/ {
        return 404;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;

    http2 on;

    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    add_header Alt-Svc 'h3=":$server_port"; ma=86400' always;
    add_header X-protocol $server_protocol always;

    server_name example.com;

    root /var/www/html;
    index index.html;

    ssl_protocols TLSv1.3;
    ssl_ecdh_curve X25519:prime256v1:secp384r1;
    ssl_prefer_server_ciphers off;

    acme_certificate letsencrypt;

    ssl_certificate $acme_certificate;
    ssl_certificate_key $acme_certificate_key;
    ssl_certificate_cache max=2;
}

Keep ssl_verify on for production. The official module has an ssl_verify off switch, but using it disables verification of the ACME server certificate; with the CA bundle above, the safer default is to verify.

The current docs list HTTP-01 and TLS-ALPN-01 as accepted challenge types. DNS-01 is not listed there. If you need wildcard certificates, verify that path before assuming native Nginx ACME covers it.

Apache can do ACME too. mod_md manages domains across virtual hosts and provides certificate provisioning via ACME. Its docs include examples with MDomain, ACME CA settings, challenge selection, renewal windows, and status integration.

Apache’s ACME problem is awareness and ceremony, not capability. You have to know mod_md exists, enable it, configure managed domains, understand virtual host interaction, and keep Apache’s TLS posture in order. In a 47-day certificate world, that is more human work than Caddy and a less direct workflow than modern Nginx.

Configuration difficulty is the visible symptom

Installation is routine in 2026. On Debian or Ubuntu, Apache and Nginx are package-manager basics. Caddy usually starts by adding the official repository, then it is also just a package install. The difference shows up in config.

Caddy can reverse proxy a public HTTPS site in three lines:

example.com {
    reverse_proxy 127.0.0.1:3000
}

That gives you HTTPS automation and, by default, HTTP/1.1, HTTP/2, and HTTP/3. Caddy also has a native JSON configuration model and an admin API. The API docs say Caddy is configured through an HTTP administration endpoint, defaults to localhost:2019, and can load new config with zero downtime while rolling back failed loads.

Nginx is manageable, but explicit. Once HTTP/3 is included, the server block is no longer tiny:

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;

    # HTTP/3 over QUIC
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    # HTTP/2
    http2 on;

    server_name example.com;

    ssl_certificate /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    add_header Alt-Svc 'h3=":$server_port"; ma=86400' always;
    add_header X-protocol $server_protocol always;

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

Readable, widely documented, easy to lint. The Nginx bargain is simple: you get a precise reverse proxy, but you own each decision unless a module or platform owns it for you.

Apache has the most moving parts:

MDomain example.com
MDCertificateAgreement accepted

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName example.com

    SSLEngine on
    Protocols h2 http/1.1 acme-tls/1

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>

Apache’s power is real, but the surface area is larger. httpd.conf, virtual host inheritance, MPM choice, .htaccess, mod_ssl, mod_proxy, mod_md, and per-directory behavior all become part of the job.

Performance, without fake benchmark theater

Nginx is still the ceiling for high-concurrency reverse proxying. Its event-driven model, mature upstream handling, low memory footprint, and tuning surface are why it remains common at the edge.

Old comparison posts often underrate Caddy. Static file serving and ordinary reverse proxy workloads are fine. For most product sites, APIs, admin panels, and internal tools, app latency and database latency will dominate the difference.

The Caddy caveat lives at the far end: very high concurrency, strict memory budgets, and tail latency under sustained proxy load. Go’s runtime and garbage collector are part of the operating model. Nginx gives you more control when that level of tuning matters.

Apache can perform well with the event MPM, but legacy shape still matters. The prefork model remains common in older PHP stacks and shared-hosting environments, and prefork is expensive per connection. .htaccess can also force per-directory checks at request time. Useful, but not free.

Market share should inform your risk model, not decide the winner. W3Techs’ web server survey in late June 2026 showed Nginx at 31.8%, Apache at 23.2%, and Caddy at 0.2% of websites whose web server W3Techs knows. Nginx and Apache have deeper operational folklore. Caddy has less market share, but its defaults remove work that older stacks still hand to the operator.

Apache’s real moat is .htaccess

Apache still owns one use case the others do not replace cleanly: .htaccess.

For shared hosting, that matters. A provider can let customers change rewrite rules, authentication, redirects, cache headers, PHP behavior, and per-directory settings without main server config access. WordPress, legacy PHP, and control-panel hosting grew around that model.

The same mechanism has a cost. .htaccess moves configuration out of one central reviewable file and into the document tree. Apache may need to check directories for override files on requests.

If you run a modern VPS, container, or single-tenant app server, .htaccess is usually a liability. If you run a shared host or a legacy app that expects it, it may be the whole reason Apache is still the right answer.

Nginx has a community split to watch

Nginx is still a strong default. Its ecosystem is less unified than it used to be.

F5 acquired NGINX in 2019, and the boundary between open source Nginx, NGINX Plus, and NGINX One remains a recurring operator discussion. In February 2024, Maxim Dounin started freenginx, whose site describes it as an effort to preserve free and open Nginx development. Angie is another Nginx-family project; its own site says the open source Angie server was created as a fork of Nginx. In 2026, “Nginx” might mean open source Nginx, NGINX Plus, freenginx, Angie, OpenResty, N.WTF packages, or a vendor platform built around Nginx semantics.

Other servers worth knowing

LiteSpeed and OpenLiteSpeed deserve a look for WordPress-heavy deployments, especially where LSCache is central. HAProxy is excellent when the job is load balancing, TLS termination, traffic routing, health checks, and proxy behavior. Traefik fits container-native routing well when your world is Docker labels, Kubernetes ingress, service discovery, and automatic Let’s Encrypt for many short-lived services. They are narrower picks than Apache, Nginx, and Caddy for a general-purpose VPS web server.

Decision guide

Choose Caddy when:

• you want HTTPS and HTTP/3 as defaults
• your team is small and ops time is scarce
• you deploy services frequently and like API-driven reloads
• you value simple config over maximum tuning depth

Choose Nginx when:

• you run high-traffic reverse proxy workloads
• you need precise upstream, caching, buffering, or rate-limit behavior
• your team already knows Nginx well
• you want native ACME but still prefer explicit server configuration

Choose Apache when:

• .htaccess support is required
• you are operating a shared-hosting or legacy PHP environment
• the application depends on Apache modules or old deployment assumptions
• HTTP/3 can wait

For a new 2026 VPS deployment, my default is Caddy for simple apps, Nginx for serious proxy and tuning work, and Apache when Apache compatibility is part of the requirement.

Dimension	Apache 2.4	Nginx	Caddy 2
First release / language	1995 / C	2004 / C	2015 / Go
Architecture	MPM process/thread model	Event-driven workers	Go runtime and goroutines
HTTP/3	No public Apache 2.4 module	Yes, official module docs still say experimental	Yes, default protocol set includes h3
ACME automation	mod_md, capable but manual	ngx_http_acme_module, native ACMEv2	Native automatic HTTPS
TLS defaults	Operator-managed	Operator-managed	Secure by default for common sites
Installation	Easy package install	Easy package install	Easy after adding official repo
Configuration difficulty	Highest	Medium	Lowest
Config and reload	httpd.conf, vhosts, .htaccess, reload	nginx.conf, graceful reload	Caddyfile or JSON API, zero-downtime reload
High-concurrency proxying	Acceptable with event MPM, weak in legacy prefork stacks	Best fit	Good for most sites
Memory profile	Can be high	Very low	Moderate
Reverse proxy / load balancing	Capable, less common as the edge default	Excellent	Good
.htaccess	Yes	No	No
Learning curve	Steep	Moderate	Gentle
W3Techs share, late June 2026	23.2%	31.8%	0.2%
Best fit	Legacy apps, shared hosting, Apache module stacks	High-traffic reverse proxy and tuned edge services	Small teams, fast launches, container and VPS apps

VPS control matters for HTTP/3

HTTP/3 needs UDP 443. Certificate automation needs reliable inbound validation or correct DNS automation. Serious web-server tuning needs root access, firewall control, kernel and sysctl visibility, logs, and a network where you can test the actual path.

A VPS is cleaner than shared hosting for this. On Riven Cloud, every plan is an unmanaged KVM VPS with full root access, a dedicated IPv4 address, a /64 IPv6 block, NVMe SSD storage, daily backups, and a 1 Gbps network port. If you are choosing a web server for users in mainland China, test the route from Tokyo or Singapore first, then compare plans on the pricing page.

Conclusion

The 2026 web server choice starts with automation. Caddy gives you the shortest path to a correct modern HTTPS setup. Nginx gives you the highest ceiling when traffic shape and proxy control matter. Apache remains the compatibility king for .htaccess, shared hosting, and old module ecosystems, but HTTP/3 absence and heavier configuration make it harder to justify for new deployments.