Repository navigation
Deploying on Azure Container Apps
A managed, autoscaling cloud deployment: a private (VNet-integrated)
PostgreSQL Flexible Server, a private Key Vault holding every secret,
and Container Apps that scale the api on HTTP concurrency and the
worker on the background-job queue depth. A sizing-tier system
(Test / Small / Medium / Large) pre-fills network, Postgres, and
replica-count sizing so you pick one option instead of reasoning about a
dozen numeric fields individually.
This page is the narrative overview. The exact parameter tables, prerequisites, and manual
az deploymentpath live indeploy/azure/README.mdin the repo, right next to the Bicep source it documents — that file is the source of truth; this page won't duplicate it.
- VNet with three subnets — Container Apps, Postgres, and a non-delegated one for the Key Vault private endpoint — plus private DNS zones for both.
- PostgreSQL Flexible Server, private access only, SKU/storage sized by the deployment tier.
- Key Vault, private-endpoint-only, holding every secret the app needs.
-
Container Apps environment:
api(external ingress, HTTP-concurrency autoscale) andworker(internal, KEDA Postgres-queue-depth autoscale), each running a DNSSEC Unbound resolver sidecar. - A migrate job that creates or updates the app's database role, runs Alembic, and bootstraps the platform admin — gated so the apps don't start until it succeeds.
- An updater job behind Update now in the admin console: runs the migrations, then moves the worker, api and itself to the new release. See Updating & Release Channels.
One radio-button choice (Test / Small / Medium / Large) pre-fills VNet CIDRs, the Postgres SKU, and api/worker replica ceilings from a single lookup table. Every value stays individually overridable. Postgres high availability is a separate, independent checkbox — not tied to any tier — since availability posture and compute size are different decisions; it's hidden for Test/Small, since Azure's Burstable Postgres tier those two use doesn't support zone-redundant HA at all.
Stable since v0.1.5: deployed on a live subscription and updated in place
with Update now. To preview a change to an existing deployment, run
az deployment group what-if first; the manual
az deployment group create -f main.bicep path is
in the repo README.
Once deployed, Onboarding Your First Organization is the same flow regardless of which deployment path you used to get there.
← Back to the README · Live demo · Report an issue · MIT licensed
- Quick Start: Docker Compose
- Deploying with Portainer
- Deploying on Azure
- Configuration Reference
- Onboarding an Organization
- IMAP Mailbox
- Google Workspace Mailbox
- Sign-in Providers
- Multi-Tenancy & RLS
- DMARC Subdomain Inheritance
- Report Attribution
- SPF Conditional Mode
- Detected Domains
- DNS Check Scheduling
- Domain Rating
🏗️ Architecture
🗺️ Roadmap