4c9fa2436e
The production images built on mutable tags with --pull, so the same commit could produce different bases, and neither Dockerfile upgraded its OS packages even though the local ones did. The published API image carried 56 HIGH and 3 CRITICAL findings, 15 of them with an upstream fix available. Pin both bases by digest and upgrade OS packages in the production images. That removes all 3 CRITICAL and 13 of the 15 fixable findings. The remaining two, msgpack and setuptools, come from a third-party SBOM; neither package is importable or listed by pip in the built image, which I confirmed rather than taking the previous report's word for it. The web image could not be fixed this way: the official 1.28 line pins nginx=1.28.3-r1 in /etc/apk/world, so apk upgrade leaves five HIGH findings in place even though Alpine ships 1.28.3-r7. Moving to nginx:alpine (1.31.6) clears them completely; 1.29-alpine scans worse, at 37 HIGH. Same uid 101 and the same template entrypoint, and the local images now use the same pinned bases so the integration suite exercises what ships. Full suite passes on nginx 1.31.6, including the browser end-to-end. With both images at zero CRITICAL, the image scan now blocks on CRITICAL and reports HIGH, instead of reporting everything. PYTHON_BASE_IMAGE and NGINX_BASE_IMAGE are wired through to the builds so a base can move forward without editing the repository, which is what PORTAINER.md already promised. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
stack.yaml— the single Portainer stack.Dockerfile.apiandDockerfile.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.