Write a Caddyfile

The one-command proxy is great for experiments, but it disappears when the terminal closes and nobody can review it. A configuration file makes routing and operational policy reviewable. Caddy’s file format is the Caddyfile, and Caddy can validate it before serving it.

Create the file

Create a file named Caddyfile (no extension) in your working directory:

http://127.0.0.1:8080 {
  reverse_proxy 127.0.0.1:4001
}

# validate with:
# caddy validate --config Caddyfile

The first line is the site address. Everything inside the braces applies to requests matching that address. The reverse_proxy directive does the same job as --to did in the previous lesson.

The explicit http:// prefix matters here. Without a scheme, Caddy assumes you want HTTPS and tries to provision a certificate. For a loopback lab on a custom port, plain HTTP is what we want for now.

Format, validate, run

Caddy ships tooling for treating this file with care:

caddy fmt --overwrite Caddyfile
caddy validate --config Caddyfile
caddy run --config Caddyfile

caddy fmt --overwrite Caddyfile normalizes indentation so diffs stay clean. caddy validate parses the file and checks it can actually load, without binding any ports. caddy run starts the server in the foreground.

Validation is the step people skip, and it’s the cheapest insurance you’ll get. Try it: delete the closing brace, run caddy validate --config Caddyfile again, and read the error. It names the line where parsing failed. Fix the brace and validation passes silently with an exit code of 0.

Verify

curl http://127.0.0.1:8080/hello
# {"port":4001,"path":"/hello"}

Same behavior as the command-line version, but now the configuration is an artifact you can commit, review, and roll back.

Treat configuration as code. Keep secrets out, review changes, and preserve the last known good version. A Caddyfile in version control with a passing caddy validate is the foundation the operations lessons build on later.