3b92813491
Some checks failed
Build and deploy / Validate source (push) Successful in 7s
Build and deploy / Integration suite on a real stack (push) Failing after 51s
Build and deploy / Secret scan and release gate (push) Successful in 9s
Build and deploy / Publish images and notify Portainer (push) Has been skipped
The production gateway does not face the internet: nginx-proxy-manager owns 80/443 on the host and proxies to it. So $remote_addr inside the gateway is that proxy, and overwriting X-Forwarded-For with it discarded the customer address the proxy had already recorded. Every request would have been attributed to one internal address, which is exactly the fault 2.1 set out to fix, reintroduced in production only. Use real_ip to take the customer address from the proxy's header, trusting only private networks. A request that reaches the published port directly from the internet is not trusted, so its header is ignored and $remote_addr stays the real peer: the anti-spoofing property is kept. Also downgrade 2.9. TLS is not missing, it is terminated by that proxy. The gap is that the repository never says so, which would break every session cookie if the stack moved to a host without one. Validated with nginx -t against the rendered production configuration. 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.