Nye-TeeOff/deploy/Caddyfile
Erol Haagenrud 1da3e32a8a Alt bekreftet og live:
https://teecup.golf → 200 OK, servert av teecup_frontend (Next.js)
https://teecup.teeoff.no → 301 permanent redirect til https://teecup.golf/, som deretter gir 200 OK
Let's Encrypt-sertifikater for teecup.golf og www.teecup.golf er utstedt og aktive
teeoff.no selv er upåvirket (samme Caddyfile, ingen endring i den blokken)
Rotårsaken til at det ikke virket tidligere var ikke feil i selve Caddyfile-innholdet (den var allerede korrekt på disk), men en klassisk Docker-fallgruve: filen på verten hadde blitt erstattet (ny inode via "skriv ny fil + rename"), mens Caddy-containerens bind-mount fortsatt pekte på den gamle, nå "foreldreløse" filversjonen. caddy reload leser fra samme stale mount og hjelper derfor ikke i et slikt tilfelle — det krever en full container-restart for å remonte fra gjeldende fil. Det forklarer trolig også hvorfor de to reload-forsøkene fra TeeCup-siden var no-ops.
2026-08-05 12:40:32 +02:00

69 lines
1.7 KiB
Caddyfile

{
email {$ACME_EMAIL}
}
www.teeoff.no {
redir https://teeoff.no{uri} permanent
}
# Gammelt domene (2026-08-05-flyttingen til teecup.golf) -- permanent
# redirect fremfor å bare slutte å svare, slik at gamle bokmerker/delte
# lenker/QR-koder på fysiske scorekort fortsatt havner riktig sted.
teecup.teeoff.no {
redir https://teecup.golf{uri} permanent
}
teecup.golf, www.teecup.golf {
encode zstd gzip
log {
output stdout
format console
}
# Offentlig, anonym lesing av opplastede bilder (MinIO, public-read
# bucket-policy) -- bucket-navnet ligger i selve stien (path-style
# adressering), derav /teecup-media/* som prefiks, ikke et eget
# subdomene (unngår en DNS-avhengighet som viste seg ikke å peke på
# denne serveren -- se CLAUDE.md-status).
handle /teecup-media/* {
reverse_proxy teecup-minio:9000
}
# WebSocket-trafikk (ADR-025, Kommunikasjon) -- rett til teecup_api,
# IKKE via Next.js sin rewrites()/teecup_frontend. Next.js proxyer ikke
# WebSocket-oppgraderinger pålitelig i "standalone"-modus; Caddy sin
# reverse_proxy håndterer Upgrade-headeren transparent uten egen config.
handle /ws/* {
reverse_proxy teecup_api:8000
}
handle {
reverse_proxy teecup_frontend:3000
}
}
teeoff.no {
encode zstd gzip
log {
output stdout
format console
}
# This upload route is implemented in Next.js, not FastAPI.
handle /api/admin/uploads/images* {
reverse_proxy frontend:3000
}
# All other /api traffic goes to the FastAPI backend.
# Use handle, not handle_path, so the /api prefix is preserved.
handle /api/* {
reverse_proxy api:8000
}
# Everything else is served by Next.js.
handle {
reverse_proxy frontend:3000
}
}