What is a Caddyfile and how do you write one?

You want your site to load with HTTPS, point to the right app, and not make you learn a whole new language just to serve a web page.

Short version: a Caddyfile is the main configuration file for Caddy, a web server that can serve websites, reverse-proxy apps, and manage HTTPS certificates automatically. You write a Caddyfile by naming the domain, then telling Caddy what to do with requests for that domain, such as serve files from a folder or pass traffic to an app running on your server.

What is a Caddyfile?

A Caddyfile is a plain text file that tells Caddy how to handle web traffic.

Think of Caddy as the person at the front desk of a building. Visitors arrive asking for example.com. The Caddyfile is the front desk instruction sheet: send this visitor to the brochure rack, send that visitor to the app upstairs, make sure everyone comes through the secure entrance.

Caddy is known for making HTTPS easier. HTTPS is the secure lock in the browser. With many web servers, you have to wire up certificates yourself. With Caddy, a simple domain block in the Caddyfile is often enough for Caddy to request and renew the certificate for you.

That does not mean the Caddyfile is magic. It is still the map. If the map points to the wrong folder, the wrong app port, or the wrong domain, your site can still break.

If you are still connecting your domain to the server, start with the domain layer first: how to point a domain at your server.

What does a Caddyfile look like?

A basic Caddyfile is made of site blocks. A site block starts with the domain name, then uses braces to say what should happen inside that domain.

For a static website, it may look like this:

caddyfileexample.com {
    root * /var/www/example
    file_server
}

In plain English, that says:

• when someone visits example.com
• use /var/www/example as the folder of website files
• serve those files as a website

For an app running behind Caddy, the Caddyfile often uses a reverse proxy. A reverse proxy is like a reception desk forwarding the visitor to a private room inside the building. The visitor sees example.com, but Caddy quietly passes the request to the app.

caddyfileapp.example.com {
    reverse_proxy localhost:3000
}

That says:

• when someone visits app.example.com
• pass the request to an app listening on port 3000 on the same server

This is common for Node.js apps, dashboards, small internal tools, and containers. If you are trying to understand where Docker fits into this picture, read Docker on a server for beginners.

How do you write a Caddyfile safely?

Start with one domain and one job.

A Caddyfile gets confusing when it tries to do too much at once. Treat it like labeling rooms in a house. First label the kitchen. Then the office. Then the garage. Do not start by drawing every pipe and wire.

A good first Caddyfile answers three questions:

1. What domain is this for?
2. Should Caddy serve files or forward traffic to an app?
3. Where exactly are those files or that app?

For a normal website, the answer might be “serve files from this folder.” For a web app, the answer might be “send traffic to this local port.”

Keep the names boring and obvious. If the project is called notes, use folders and comments that say notes. Future you will not remember that project-new-final-2 was the important one.

You should also keep each site block separate. If you host multiple domains on the same server, each domain should have its own clear section. That way one project is less likely to break another when you edit it later. This matters especially when you host more than one website on the same machine; the goal is to avoid a single tangled file where every change feels risky.

What goes wrong with a Caddyfile?

Most Caddyfile problems are not dramatic. They are small mismatches.

The domain may not point to the server yet. In that case, Caddy might be fine, but visitors are not reaching it. DNS, the internet’s address book, has to send the domain to the right place before Caddy can help.

The app may not be running on the port listed in reverse_proxy. If your Caddyfile says localhost:3000 but the app is actually on localhost:8080, Caddy is knocking on the wrong door.

The folder path may be wrong. A static site block can be perfectly written, but if root points at an empty folder, visitors will not see the site you expected.

HTTPS can also fail when the domain is not reachable from the public internet, when ports are blocked, or when old certificate assumptions are still hanging around. Caddy handles a lot for you, but it still needs the outside world to reach it correctly. For the bigger picture, see how to get free HTTPS on your own server.

When something breaks, the exact error string matters. Browser messages like ERR_CONNECTION_REFUSED, SSL_ERROR_INTERNAL_ERROR_ALERT, or Caddy log messages about certificate issuance are clues, not decoration. Logs are the notebook that tells you what Caddy tried to do; if you are new to them, read how to read server logs when something breaks.

FAQ

Is a Caddyfile the same as Caddy? No. Caddy is the web server. The Caddyfile is one way to configure Caddy.

Where is the Caddyfile stored? It depends on how Caddy was installed, but the important idea is that Caddy reads this file to know how to route traffic.

Do I need a Caddyfile for HTTPS? Often, yes. The Caddyfile tells Caddy which domain it should manage HTTPS for.

Can one Caddyfile host multiple websites? Yes. You can add separate site blocks for separate domains, as long as each block stays clear.

Is Caddy easier than nginx? For many small sites and apps, yes, especially because Caddy handles HTTPS automatically. But you still need a clean setup.

The shortcut

Server Manager helps by keeping the moving parts visible: which domain belongs to which project, where traffic is supposed to go, and whether HTTPS is part of the setup. That spares you from the common Caddyfile mistakes above, like pointing a domain at the wrong app port, losing track of which folder serves which site, or leaving a certificate problem buried in a file you have not opened for months.

The real benefit is that the setup stays legible over time. When you come back later to add another site or fix a broken one, you are not decoding a private puzzle made from old edits, half-remembered ports, and copied snippets.

You still own the server and the choices. You just spend less of your attention on keeping the instruction sheet understandable.

A Caddyfile is not something to fear. It is a short set of instructions: this domain, this destination, this kind of traffic handling. Once those pieces are clear, Caddy becomes much easier to reason about — and your site is less likely to break because of one hidden mismatch.