feat: deploy through shared Caddy ingress

docs/decisions/0006-use-existing-caddy-ingress.md

@@ -0,0 +1,21 @@
+# 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.