Choosing a reverse proxy is partly a technical decision and partly a question of how you want to manage changes. Caddy and Nginx Proxy Manager can both route requests to self-hosted apps over HTTPS, but they offer different day-to-day workflows: Caddy is commonly configured with text files, while Nginx Proxy Manager (NPM) provides a browser-based dashboard for managing proxy hosts and certificates.
The right choice is usually the one you can configure, back up, and recover with confidence—not a presumed winner in a performance contest.
The practical difference
With Caddy, you describe routes in a Caddyfile. That configuration can be reviewed, copied, and stored alongside other deployment files. Caddy can also obtain and renew certificates automatically when the domain and network setup meet the requirements.
With NPM, you create proxy hosts in a web interface: enter a hostname, specify an upstream, and configure certificate and SSL options there. This can make common changes easier to manage without editing a proxy configuration file.
| If you prefer… | Consider… |
|---|---|
| A dashboard for adding and editing proxy hosts | Nginx Proxy Manager |
| Readable configuration that can be reviewed and versioned | Caddy |
| A form-based workflow for common host and certificate tasks | Nginx Proxy Manager |
| Automating proxy configuration as part of a deployment | Caddy |
This is a comparison of Caddy and NPM, not Caddy and manually maintained Nginx configuration. NPM is a management interface for an Nginx-based proxy; Caddy is the web server and proxy you configure directly. For a broader comparison of the two proxy products, see Caddy and Nginx compared directly.
Follow one request through either setup
Suppose an app called notes listens on port 3000 inside a Docker network, and you want notes.example.com to reach it.
A simple Caddyfile route looks like this:
notes.example.com {
reverse_proxy notes:3000
}
The hostname notes must be resolvable from the Caddy container. In a typical Docker setup, that means the proxy and app can reach each other over a shared Docker network.
In NPM, you would create a Proxy Host for notes.example.com, enter the upstream host and port, and save it. If NPM is containerized, it also needs network access to the app. Using a dashboard doesn’t remove the need to get DNS and container networking right; it just changes how you enter and maintain the proxy settings.
In both cases, check the whole path: the domain must resolve to the proxy’s public address, the proxy must be reachable on the required ports, and the proxy must be able to connect to the app.
HTTPS still depends on DNS and reachability
Caddy’s automatic HTTPS is convenient, but it isn’t independent of the surrounding network. Public certificate issuance depends on the hostname and validation requirements being satisfied. In a typical public setup, inbound access to ports 80 and 443 must be available to the proxy for common HTTP-based validation and traffic.
NPM lets you request and manage certificates through its interface. The dashboard simplifies the operation, but it cannot fix a hostname pointing at the wrong address or a firewall blocking the needed traffic. Special cases—such as a service behind a CDN or a wildcard certificate—may need a different validation approach. Wildcard issuance typically uses DNS-based validation, which depends on your provider and deployment.
If certificates or redirects are involved, check that the layers in the request path agree about the public scheme and forwarded headers. This Let’s Encrypt and Nginx overview provides useful context on the DNS, port, and server-name prerequisites for certificate setup.
Think about recovery before you pick
The two workflows also store configuration differently, which matters when a container is replaced or a host fails.
With Caddy, proxy rules are commonly in the Caddyfile. In a container deployment, mount that file and preserve the persistent data your chosen setup needs, including certificate state if you want to retain it. A copy of the Caddyfile alone may not preserve all deployment state.
NPM stores its host settings in persistent application data, with certificate material in its configured certificate storage. Back up the relevant persistent locations together, and use a consistent procedure if the application’s database may be changing during the backup. Recreating the container without its persistent data can leave you with what looks like a fresh installation.
For either option, protect private keys and secrets in backups. A useful recovery test is to restore the configuration and required data in a replacement or test deployment, then verify that a hostname reaches the right upstream and serves HTTPS as expected.
Don’t switch just for a generic performance claim
For a small home lab with a handful of apps, performance is often not the first factor to decide the setup. Resource use depends on the workload, configuration, TLS settings, logging, traffic, and hardware. There is no universal speed verdict without comparing equivalent configurations under representative conditions.
If performance matters for your environment, test your own routes and observe CPU, memory, latency, and errors. Otherwise, choose the workflow that makes routine changes and recovery easier for you.
A safe way to decide
Start with one non-critical app rather than migrating everything at once. Configure its hostname and upstream, confirm that the proxy can reach the app, and test HTTP and HTTPS. Then make sure you know where the active configuration and certificate data live, and how you would restore them.
Choose Nginx Proxy Manager if you want common proxy-host tasks in a browser dashboard. Choose Caddy if you prefer a compact, reviewable configuration and a workflow that fits naturally with version-controlled deployment files. Either can be a good fit when DNS, networking, HTTPS, and persistent data are handled deliberately.
I originally published a more detailed version of this guide on the SSHFlow blog.
I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.
Top comments (0)