Claude
debb1e023c
Serves the static index.html via a small nginx container and documents pointing an existing Caddy 2 instance (local or remote) at it via FQDN with automatic HTTPS. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PbwKCCj1vwAoqgRYDoqgeL
1.7 KiB
Hosting with Docker + Caddy 2
The game is a single static index.html, so it's served from a small nginx
container. Caddy sits in front as a reverse proxy and handles the FQDN + TLS.
1. Build and run the container
docker compose up -d --build
This builds the image from Dockerfile (nginx serving index.html) and
exposes it on http://<docker-host>:8080. Check it directly first:
curl http://localhost:8080/healthz # -> ok
Change the 8080:80 mapping in docker-compose.yml if that port is taken.
2. Point Caddy at it
Caddy can run on the same host as the container or on a different
machine — either way it just needs a reverse_proxy pointed at the
container's exposed port.
Add a block like this to your existing Caddyfile (replace
drums.example.com with your real FQDN):
drums.example.com {
reverse_proxy localhost:8080
}
If Caddy runs on a different machine than the container, use the docker
host's address or internal hostname instead of localhost:
drums.example.com {
reverse_proxy 10.0.0.5:8080
}
Then reload Caddy:
caddy reload --config /path/to/Caddyfile
Caddy 2 automatically requests and renews a TLS certificate for the FQDN (via Let's Encrypt) the first time it's reloaded with a public domain name in the block — no extra config needed, as long as the FQDN's DNS A/AAAA record already points at the Caddy host and ports 80/443 are reachable.
3. Updating
Since the game is one file, redeploying after a code change is:
docker compose up -d --build
nginx serves the new index.html immediately; no Caddy reload needed unless
you changed the Caddyfile itself.