9926d3ab55
deploy/stack.yaml arrived in the first commit and was never deployed. Portainer runs the repository's docker-compose.yml. Keeping both meant two definitions drifting apart, with the documentation naming the one nobody used, which is how the credential question came up at all. The hardening it offered is narrower than it looks: Docker secrets keep values out of docker inspect and the Portainer console, but local/secrets.py loads them into the process environment regardless, and anyone able to read docker inspect can already read the secret files. With a single Portainer user, the benefit that remains does not outweigh maintaining a divergent copy. local/secrets.py stays: inert against the deployed file, and it lets a stack switch to Docker secrets later without touching code. The preflight and its tests degrade cleanly when no such stack is present. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
17 lines
903 B
Markdown
17 lines
903 B
Markdown
# Production deployment files
|
|
|
|
The DTF application is one Portainer-owned Docker Swarm stack. Gitea builds,
|
|
tests, scans, and publishes the two application images, then calls the stack's
|
|
Portainer webhook. Start with the short operator guide in `../PORTAINER.md`.
|
|
|
|
- The deployed stack is the repository's `docker-compose.yml`, not a file here.
|
|
- `Dockerfile.api` and `Dockerfile.web` — prebuilt registry images.
|
|
- `portainer.env.example` — non-secret Portainer variables.
|
|
- `production_preflight.py` — fail-closed application/configuration validator.
|
|
- `PRODUCTION_CHECKLIST.md` — production evidence checklist.
|
|
|
|
The current application remains deliberately blocked from production because
|
|
real adapters and Docker-secret file loading are absent and current validation
|
|
base images have unresolved HIGH/CRITICAL findings. No real provider or
|
|
production service has been configured or contacted.
|