7. Deployment¶
Full deployment architecture is documented in architecture/irap.md (the IRAP-specific three-layer pattern) and architecture/architecture.md §Deployment (the general deployment story). This page will eventually contain the summary view.
The three environments¶
| Environment | Purpose | Host |
|---|---|---|
| Integration | Continuous deployment target; merge-queue tests integration | bastion / shared dev host |
| Staging | Pre-production verification; regression suite | staging host |
| Production (commercial) | SaaS tenants | production host (commercial) |
| Production (IRAP) | Government / OFFICIAL:Sensitive tenants | isolated IRAP host |
All environments run the same Elixir release. The differences are runtime configuration (AI provider, secrets, domain, TLS certs) and the presence or absence of the Go proxy (IRAP-only).
Deployment tool¶
Kamal (zero-downtime Docker-based deploy, Basecamp). Configured per
ADR-014-F:
reuse the infrastructure pattern from the existing AgenticAI-app Laravel
deployment — same bastion, same Kamal patterns, same Bitwarden Secrets
Manager pattern.
Deployment config is story-tracked as STORY-F-011 (integration deploy) and STORY-F-020 (staging + production).
The IRAP boundary (Layer 3)¶
For the IRAP deployment, a small Go reverse proxy (~500 LOC) sits in front of the Elixir app and enforces:
- Session timeout (15 min idle, ISM requirement)
- Request-size limits
- Origin pinning to the IRAP tenant's approved domains
- FIDO2 WebAuthn enforcement before session establishment
- Traffic routing to Bedrock Sydney only (no other AI providers reachable)
The Elixir app itself is identical in both deployments; the IRAP constraints live in the proxy so the business logic stays clean.
Full details: architecture/irap.md.