ADR-0004: Dokploy Deployment Platform
Status
Accepted
Context
Ez FactoryOS richiede ambienti isolati stile Odoo.sh: feature/* → dev → staging → main con database, Redis, volumi e variabili separati per ambiente.
ADR-0003 valutava Railway come piattaforma candidata. La decisione operativa e' passare a Dokploy su VPS per gestione Docker Compose, domini TLS, variabili runtime, volumi e deploy via webhook/API.
GitHub Actions gestisce CI, build immagini GHCR, promozione tra ambienti, backup applicativi, migrazioni, health check e rollback.
Decision
Usare Dokploy come piattaforma di deploy server-side:
| Environment | Branch Git | Scopo | Dominio |
|---|---|---|---|
development | dev | Sviluppo integrato / server dev | dev.<dominio> |
staging | staging | Validazione cliente e test migrazioni | staging.<dominio> |
production | main | Produzione | <dominio> |
Sviluppo locale resta su Docker Compose + Makefile (make up).
Stack server basato su compose vendorizzato da frappe/frappe_docker con immagine custom ghcr.io/<org>/ez-factoryos.
Production promuove la stessa immagine validata in staging tramite digest SHA256, senza rebuild.
Consequences
- Railway e relativi artefatti rimossi dal repository.
- Struttura
deploy/come unica fonte per compose, Docker, env e template Dokploy. - Secrets solo in GitHub Environments e Dokploy, mai nel repository.
- Dokploy gestisce proxy/TLS; il compose espone
frontend:8080. - Backup pre-deploy obbligatori per staging e production.
- Staging disabilita email/webhook reali via
scripts/staging-safety.sh.