Caddy foundations

Run disposable servers

Use Caddy’s command shortcuts to serve one response and one directory before creating persistent configuration.

You don’t need a configuration file to try Caddy. The CLI has two shortcuts that start a working server from one command. I use them for quick experiments, to check if a port is free, or to share a folder on my laptop for five minutes.

Serve one fixed response

caddy respond starts a server that always returns the same body:

caddy respond --listen 127.0.0.1:8080 --body 'hello from Caddy'

Open another terminal and call it:

curl http://127.0.0.1:8080/

You get hello from Caddy back. That single line proved three things: the binary runs, the port is free, and HTTP flows end to end.

This is my favorite debugging tool when a network problem shows up. A server this dumb cannot fail for interesting reasons. If curl can’t reach it, the problem is the network, the firewall, or the port, not the application.

Serve a directory

Stop the first server with Ctrl-C. Now let’s try caddy file-server, which serves the files in a folder:

mkdir -p public && echo '<h1>Hi</h1>' > public/index.html
caddy file-server --listen 127.0.0.1:8080 --root ./public --browse

Request http://127.0.0.1:8080/ and you get your HTML back. The --browse flag adds a directory listing for folders without an index file, so you can click around like in a file manager.

Stay on loopback

Notice that both commands listen on 127.0.0.1. That address is loopback: only programs on this machine can reach it. Write :8080 instead and Caddy binds to every interface, so every device on your network can reach the server.

With caddy respond that’s harmless. With caddy file-server it’s not. A directory can contain .env files, source code, or a database dump you forgot was there. My advice is to start on loopback and widen access on purpose, never by accident.

When the port is taken

Sooner or later you’ll start a server and Caddy will exit right away with an error like this:

bind: address already in use

Something else is already listening on that port. Find it with lsof -i :8080 on macOS or ss -lntp on Linux. Then stop that process, or pick a different port.

Try this on your own: start caddy respond on port 8080, then start caddy file-server on the same port in a second terminal. You’ll see the error, and you’ll know exactly what it looks like the next time it shows up for real.

Lesson completed