starcoach-hackathon/zarinpal-analytics-deployment
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: deploy through shared Caddy ingress

Browse Source
This commit is contained in:
Amirhossein Khalili
2026-08-22 21:48:26 +08:00
parent e2decb9e01
commit 64404bb7cf
9 changed files with 473 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/PLATFORM-OPERATIONS-SPEC.md
View File

@@ -6,6 +6,8 @@
- Depends on: all deployable backend and frontend capability contracts
- Last updated: 2026-08-20
> **2026-08-22 ingress amendment:** ADR 0006 supersedes the dedicated Nginx/Certbot edge described below. The host's existing Caddy deployment owns ports 80/443, TLS, canonical-host routing, security headers, API/SSE proxying, and frontend proxying. This project publishes no ports and attaches only `backend` and `frontend` to the external `caddy_proxy` network. All private-data, manual-release, migration/import, secret, health, backup, and recovery requirements remain in force.
## Confirmed intent
Deploy `zarinpal.amiirkhl.ir` on one Ubuntu server using the proven Qlockify operating model: three nested Git repositories, Docker Compose builds performed on the server, Nginx as the only public entry point, automatic Let's Encrypt TLS, PostgreSQL 18, Redis 7 Alpine, a Go API and event-driven worker, and a static frontend.

2
docs/QLOCKIFY-ADAPTATION-CONTRACT.md
View File

@@ -2,6 +2,8 @@
- Status: Approved planning baseline
- Source: `D:/Programing/Scripts/Qlockify/qlockify-deployment` (read-only)
> **2026-08-22 ingress amendment:** ADR 0006 replaces the copied Nginx/Certbot edge with the host's existing Caddy deployment and external `caddy_proxy` network. Qlockify's nested-checkout, manual-build, environment, data-service, and operational patterns remain the baseline; its edge container and certificate lifecycle do not.
- Target: `/home/ubuntu/zarinpal-analytics-deployment`
- Implementation authorization: Granted by user on 2026-08-20
- Last updated: 2026-08-20

21
docs/decisions/0006-use-existing-caddy-ingress.md Normal file
View File

@@ -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.