22 lines
1.6 KiB
Markdown
22 lines
1.6 KiB
Markdown
# ADR 0006: Use the existing shared Caddy ingress
|
|
|
|
- Status: Accepted
|
|
- Date: 2026-08-22
|
|
|
|
## Context
|
|
|
|
The production host already runs a dedicated Caddy Compose project that owns ports 80/443, TLS certificates, and subdomain routing for Gitea, Penpot, Uptime Kuma, and other services. Running the previously planned Nginx/Certbot edge in this project would conflict on host ports and duplicate certificate ownership.
|
|
|
|
## Decision
|
|
|
|
ZarinPal Analytics connects its frontend and API containers to the existing external `caddy_proxy` Docker network using the stable aliases `zarinpal-frontend` and `zarinpal-backend`. Caddy routes `zarinpal.amiirkhl.ir` to those aliases. This Compose project publishes no host ports and owns no TLS material.
|
|
|
|
PostgreSQL, Redis, the worker, migration, importer, and admin services remain on an internal data network. Only the API additionally joins `caddy_proxy`; the frontend joins only `caddy_proxy`. Caddy preserves the complete `/api` path and disables response buffering for proxied API traffic so authenticated SSE streams are delivered promptly.
|
|
|
|
## Consequences
|
|
|
|
- The Caddy deployment must exist first and create the external `caddy_proxy` network.
|
|
- Caddy configuration and this deployment must be released together for first activation.
|
|
- Nginx/Certbot-specific requirements in the earlier platform documents are superseded by this ADR. Their routing, TLS, and port-ownership intent is retained and implemented by the shared Caddy service.
|
|
- The shared proxy network is a trusted infrastructure boundary; no database, Redis, worker, or administrative service is attached to it.
|