Enterprise deployment

The reference deployments in deploy/ run Farrier the way a security review expects: the engine has no public address, every credential comes from the platform's secret manager through a workload identity, the master key is wrapped by a cloud KMS key, and data at rest is encrypted with customer-managed keys.

Each Terraform module has a README.md with inputs, outputs, apply steps, a bring-your-own-network section, cost notes and teardown, and an examples/minimal.

Why the engine is never public

The engine holds the keys to your fleet: it can sign certificate requests, push certificates to load balancers and firewalls, and read device credentials. Only the dashboard needs to talk to it, so every reference deployment keeps it off the internet:

• AWS: the engine sits behind an internal ALB whose security group admits only the web tasks. Even the web ALB is internal; CloudFront reaches it through a VPC origin.
• Google Cloud: the engine's Cloud Run ingress is internal. The web service reaches it through Direct VPC egress.
• Azure: the engine's Container Apps ingress is limited to its environment.
• Compose: the engine is on an internal Docker network with no published port.

Its outbound path, to ACME CAs, DNS APIs and your devices' management interfaces, goes through your VPC: NAT for the internet, and VPN, Direct Connect, Interconnect or ExpressRoute to the devices.

AWS

Internet ─HTTPS─> CloudFront ─VPC origin─> internal ALB ─> web (Fargate)
                  caches /_next/static/*, /assets/*            │ FARRIER_API_URL
                                          internal ALB ────────┘ (web security group only)
                                               │
                                          engine ×2 ─> RDS · S3 · Secrets Manager · KMS · devices

Google Cloud

Internet ─HTTPS─> external ALB + Cloud Armor ─┬─ static paths ─> backend with Cloud CDN ─┐
                                               └─ everything else ─> backend, no CDN ──────┴─> Cloud Run web
Cloud Run web ─VPC─> Cloud Run engine (internal) ─VPC─> Cloud SQL private IP · Cloud NAT · devices

Cloud Run cannot pull from ghcr.io, so the module creates an Artifact Registry remote repository that proxies it. On GKE, use the Kubernetes manifests with Workload Identity and keep the data tier from the module.

Azure

Internet ─HTTPS─> Front Door Standard ─(static paths cached)─> web app
Container Apps environment (VNet): web app ─> engine app (environment-only ingress)
engine ─> PostgreSQL (delegated subnet) · Blob and Key Vault (private endpoints) · devices

On-prem

deploy/compose/production.yml runs two engine replicas, the web app, PostgreSQL 16 and MinIO on one host, with Docker secrets instead of environment literals, read-only root filesystems, all capabilities dropped and no-new-privileges. Keep device credentials in HashiCorp Vault with FARRIER_SECRET_BACKEND=hashicorp. See deploy/compose/README.md.

Configuration contract

Every deployment configures the same variables.

Engine

Cloud backends always authenticate with the platform identity: an ECS task role, a Cloud Run or GKE service account through Workload Identity, an Azure managed identity, or Vault's Kubernetes auth. Never give the engine static cloud keys.

Web app

Deploy with a module

cd deploy/terraform/aws/examples/minimal   # or gcp, azure
terraform init
terraform apply                            # infrastructure and empty secrets
# wrap the master key with the module's KMS key and store it (see the module README)
terraform apply -var secrets_seeded=true   # start the services

The two-step apply keeps the master key out of Terraform: you generate it, wrap it with the module's key, and store only the ciphertext. Generated API tokens and the session secret do pass through state, so keep state in an encrypted, access-controlled backend.

After deploying, work through the hosting checklist, and see Databases and HA for replicas and migrating from SQLite.