Caddy server setup: automatic TLS, reverse proxy, HTTP/3

Installing Caddy: where TLS and proxying break

Installing Caddy takes a few minutes: a single binary, a short config, and certificates are issued automatically. It is precisely because of this ease that it is often done hastily—and a few months later, downtime appears where none was expected.

Most failures are certificate errors. Automatic issuance fails if domain validation hits a closed port or the DNS record points to an old address.

Then an expired certificate lives on until the first call: the reverse proxy responds, but the browser shows a warning instead of the application.

The second class is configuration drift across multiple nodes.

While routes are edited by hand, each server runs its own version of the rules: some traffic goes to the wrong place, updating one node changes the behavior of the entire environment, and the cause is then sought in access logs.

The third is failures when updating routes. A config reload at peak, a rule conflict after migration, lost headers: externally this looks like service downtime, even though the application never crashed. It is measured in minutes of unavailability, not by the number of errors in logs.

Below we break down how this is addressed: where exactly TLS and proxying break, why failures surface months later, and which checks eliminate these scenarios in advance.

What certificate and reverse proxy automation provides

Automatic TLS in Caddy is designed so that a certificate is issued on the first request to a domain and renewed well before expiration—without manual steps or calendar reminders. Issuance takes seconds: from applying the configuration to a working HTTPS connection.

The class of incidents “the certificate expired on a weekend night” disappears along with manual rotation.

The reverse proxy becomes a single entry point: one node faces outward, and routing rules distribute requests across internal services—application, admin panel, API, static content.

The route lives in the configuration next to the domain, so a new service is connected by editing a single block, not with a second ingress address and a separate certificate scheme.

What this gives in measurable terms: certificate issuance time is seconds instead of hours of back-and-forth, and the failure rate during updates is close to zero because renewal is verified in advance.

Switching between services is one configuration change applied without downtime. Issuance and renewal events go into monitoring, so a failure is visible before users report it.

If there are several services and they are spread across different nodes, the transition is done gradually: part of the domain is moved to the new node, headers, cache behavior, and redirects are verified, and only then is the rest switched over.

This way a single entry point is assembled without stopping operations, and rollback to the previous scheme remains available at every step.

Server deployment methods: package, container, build

Caddy installation options differ not in the startup command, but in how the service lives afterward: who updates the binary, where the configuration is read from, and how quickly you can roll back to the previous version on failure. You should choose based on the operational environment, not the convenience of the first launch.

How to choose the mode

If there is a single proxy and no orchestrator nearby, a system service has fewer moving parts. When there are several environments, a container removes drift between environments and simplifies rollback.

Build is chosen only if there are no ready-made installation options for the platform: the maintenance cost here is higher.

Caddy installation and configuration: engineering work stages

Audit, not installation, is the first step: Caddy is described declaratively, and an error in the base configuration manifests not at startup, but on the first certificate renewal or when the application behind the proxy is unavailable.

Therefore, we first record the current scheme, then install, and only after verifying routes hand it over to operations.

1. Configuration audit. We gather what the web layer serves, where TLS terminates, which domains and ports are occupied, and who owns the certificates. We note points where automatic renewal conflicts with an external load balancer.
2. Route scheme. We define the area of responsibility: what Caddy takes over and what remains on the external perimeter. We agree on the domain list and redirect rules before work begins.
3. Installation and basic configuration. We install from the official repository, set up the system service, port permissions, and certificate directory. The configuration lives in a repository and is not edited manually on the machine.
4. Routes and certificates. We describe virtual hosts, application addresses, and headers. We enable automatic issuance and renewal, check the chain and behavior when moving a domain.
5. Route verification. We run through all addresses and methods: response codes, redirects, behavior when the application is unavailable, and boundary request sizes. We separately verify rollback to the previous configuration.
6. Documentation and handover to operations. We hand over configurations, the route scheme, the procedure for edits, and diagnostic scenarios. We walk through them with the team that will be on duty.

Configurations, routing schemes, and procedures

The result of the work is not just a running service, but a set of artifacts by which it can be developed and restored without the author of the changes. Below is exactly what we hand over for Caddy and how it fits into your repository, monitoring, and on-duty instructions.

• Server configuration files: domains, backend addresses, forwarding rules, security headers, request size and time limits—separately by environment and with versioning.
• Traffic routing scheme: where the request comes from, where encryption terminates, which paths go to application services, and what happens when a node fails.
• Automatic certificate issuance and renewal: where keys are stored, how renewal is verified, and who receives a notification if the expiration date is approaching.
• Access policies: restricted service routes, address restrictions, and separation of privileges between environments and roles.
• Maintenance procedure: how a change is prepared and verified, the procedure for applying it without downtime, and the criteria and procedure for rollback.
• Configuration backups: what is included in the backup (configuration, certificates, state), frequency, storage location, and recovery verification.
• Observability and instructions: metrics, access and error logs, retention periods, alert thresholds, typical failures, and on-duty actions.

Acceptance is based on these files, not on the fact that “the site opens”: we deploy the configuration from a backup on a clean node and compare the routing scheme with real traffic.

Case study: migration to a reverse proxy with automatic TLS

Before the work, the scheme relied on a reverse proxy with manual TLS termination: certificates were issued by a script on a schedule, configurations were edited directly on production nodes, and HTTP/3 was enabled by separate directives in each of them.

Renewal could fail silently—the problem was discovered through complaints about unavailability. Recovery after such a failure took about 40 minutes and required logging in to a specific machine.

What was changed

We moved termination to Caddy: certificates are issued and renewed automatically, the configuration is described declaratively in a single file and stored in a repository with mandatory review.

Adding a domain came down to one entry instead of six manual actions, and HTTP/3 is enabled by a directive rather than a separate build. We switched one node at a time, with response verification on live traffic and instant rollback to the previous commit.

Metrics before and after

Recovery time was reduced from 40 minutes to 3: node state is described in the configuration rather than assembled by hand, so rollback proceeds together with the change history. Incidents with expired certificates—four per quarter before the work, zero after. Provisioning a new environment accelerated from several hours to minutes.

A separate effect is change predictability: configuration checks run on every commit, so the share of paths covered by automated checks grew from zero to full. Drift between environments, which previously was found only during incident analysis, is now visible before deployment.

What to do if a reverse proxy is already deployed?

The reverse proxy does not have to be removed: a new Caddy environment is brought up alongside on free ports, and the entry point is changed in a controlled manner. The old configuration remains operational, so a path back exists at any moment.

There are two schemes: parallel operation, when the previous proxy remains the entry point and forwards requests further, and domain-by-domain migration, when servers share ports and each domain moves separately. The first provides smoothness; the second provides cleaner logs and clearer diagnostics.

Before switching, they check what breaks most often: forwarding of the original client address and request scheme, long-lived connections and file resume, and behavior when the upstream server is unavailable.

They separately record the DNS record TTL—with a large cache, some clients will continue to hit the old address long after the switch.

We keep both environments in a repository as configuration, so rollback is returning the previous entry point, not restoring a server from scratch. Switching takes minutes, and monitoring metrics then proceeds without haste.

Common technical questions about TLS and reverse proxy

Restart and migration are the two scenarios that most often break trust in automatic TLS. Certificates are stored on disk next to the configuration: after a restart, the reverse proxy brings up already issued ones without contacting the certificate authority.

During migration, it is enough to copy the directory with keys and switch the domain—issuance and renewal continue on their own.

How does the solution behave under load?

The proxy consumes memory per connection and hits network throughput before CPU. The limit is set by timeouts and a concurrent connection limit, so behavior at peaks is predictable and configured in advance, before traffic starts.

Who is responsible for renewal, and where are the solution's limitations?

The server initiates renewal itself several weeks before expiration and retries on failure; we set up alerts for failed attempts so we can intervene in advance.

There is one limitation: dynamic configuration is more complex than static, and some scenarios—for example, routing by request content—require a separate module or an intermediate service. We record such places in the scheme so the configuration does not grow blindly.

Let's discuss the task: what to prepare for the first conversation

To turn the conversation about Caddy installation into a concrete estimate and plan rather than a series of clarifying questions, it helps to gather the input data in advance.

They determine the scope of work, the switching order, and the timeline: the more precise the input, the fewer assumptions remain in the plan.

• List of domains and subdomains: which face outward, which live only on the internal network, and where TLS should terminate.
• Where DNS zones are hosted and whether there is programmatic access to the provider—automatic certificate issuance and renewal depend on this.
• Which services the proxy fronts: ports and paths, long-lived connections, static content, and health check addresses.
• Current configuration: what is at the entry point now, which files and rules are involved, and what is blocking migration.
• Network scheme and access: how an engineer gets onto the machine, whether web traffic ports are open from outside, and whether there is an intermediate node.
• TLS and HTTP/3 requirements: whether strict policies, mutual authentication, and priority for modern clients are needed.
• Time constraints: whether live traffic can be switched, whether there is a window for the work and a separate one for rollback.

After that, we come back with an estimate and plan: a list of stages, what and when changes on production traffic, rollback points, and timelines. Describe the task in free form—we will clarify the missing details ourselves.