Ctrl K
ComunidadGuías…

Caddyfile.single-server

Rama main · réplica de lectura del repositorio original.

Archivo original ↗Preguntar a KiBot
# Um domínio, duas superfícies: as APIs públicas do Supabase seguem para o
# Envoy privado; todo o restante segue para o app. Studio e Postgres não são
# publicados.

{
	email {$ACME_EMAIL}
}

{$DOMAIN} {
	encode gzip

	route {
		# O webhook global do WAHA só pode ser chamado pela rede interna.
		@waha_global path /api/v1/webhooks/waha
		respond @waha_global 403

		# Superfícies públicas necessárias aos SDKs Supabase no navegador.
		@supabase path /auth/v1* /rest/v1* /realtime/v1* /storage/v1* /functions/v1* /graphql/v1*
		reverse_proxy @supabase supabase-envoy:8000

		reverse_proxy app:3000
	}
}

# ── Ponto de extensão (#2724) ────────────────────────────────────────────────
# Publicar OUTRO serviço no mesmo VPS (wiki, landing page, n8n) sem editar
# este arquivo: solte um arquivo seu em `caddy-sites/` — a pasta local que o
# compose monta em /etc/caddy/sites, somente-leitura — e o Caddy publica aquele
# serviço em seguida. Exemplo comentado em caddy-sites/README.caddy.
#
# Mesma razão do Caddyfile da base: este arquivo entra no contêiner por bind
# mount de um arquivo e o update.sh troca de versão com `git checkout <tag>`;
# com o arquivo alterado a atualização para em "parece haver mudanças locais
# que divergem". As duas variantes (single-server e normal) têm o mesmo ponto
# de extensão.
#
# O caminho tem de ser o MESMO que o bind mount do compose declara; se os dois
# divergirem o glob não acha nada e só avisa no log (a régua em
# tests/unit/ponto-de-extensao-do-caddy.test.ts acopla os dois).
import /etc/caddy/sites/*.caddy