caddy-local-https

caddy-local-https

Local development usually means a pile of localhost:3000, localhost:8000, localhost:8100 URLs — easy to mix up, no HTTPS, and cookies/CORS/service-worker behaviour that does not match production. Caddy fixes this with a few lines of config: real hostnames, automatic HTTPS, one front door for several backends.

Use this skill when

• You are running two or more local services and want to reach them by name instead of by port.
• You need HTTPS locally because the app's behaviour depends on it (secure cookies, service workers, SameSite, OAuth redirect URIs).
• You want one hostname to route to several backends by path (/api/* to one service, everything else to another).

Why .localhost and Caddy's internal CA

• The .localhost TLD always resolves to the loopback address — no hosts file editing, no DNS setup. myapp.localhost just works.
• Caddy ships an internal CA. For .localhost (and other internal names) it issues its own certificates automatically and, on first run, offers to install its root into the system trust store. Once trusted, https://myapp.localhost is green in the browser with zero per-site certificate work.
• This is for local development only. Caddy's internal CA is not trusted by anyone else's machine. For a public-facing site Caddy does real ACME/Let's Encrypt issuance instead — different mode, not what this skill covers.

Minimal Caddyfile — one hostname, one backend

myapp.localhost {
	reverse_proxy 127.0.0.1:3000
}

That is the whole file. caddy run --config ./Caddyfile (or caddy reload if it is already running) and https://myapp.localhost proxies to your app on port 3000, with HTTPS terminated by Caddy.

Path-based routing — one hostname, several backends

When a single app is really a frontend plus an API plus another service, route by path with handle blocks:

myapp.localhost {
	handle /api/* {
		reverse_proxy 127.0.0.1:8000
	}
	handle /embedding/* {
		reverse_proxy 127.0.0.1:8100
	}
	handle {
		reverse_proxy 127.0.0.1:3000
	}
}