# Caddy in front of the stack: one hostname, TLS from Let's Encrypt, everything
# behind it spoken to over the compose network in plain HTTP.
#
# Both doors are the same door here. Browsers get the Web App; chargers dial
# /ocpp/{serial} on the same hostname, and the BFF carries that through to the
# API Server. Caddy proxies WebSocket upgrades without being told to, so there
# is nothing to configure for the charger case.
#
# DV_DOMAIN and DV_ACME_EMAIL come from .env via docker-compose.tls.yml.

{
	email {$DV_ACME_EMAIL}
}

{$DV_DOMAIN} {
	encode zstd gzip

	# X-Forwarded-Proto is set by Caddy to the scheme the client used. The API
	# Server reads it to decide a charger arrived over TLS, which is why the
	# web-app service is given TRUST_FORWARDED_PROTO=true — without that the BFF
	# would overwrite this header with its own plaintext hop and a charger would
	# be rejected under OCPP_REQUIRE_TLS.
	reverse_proxy web-app:8090
}