Choose your deployment target

Applies to: Self-Managed

This section is for running DVARA in your own infrastructure (self-managed) or on a dedicated cluster we operate for you (managed hosting). Not sure which applies to you? See Deployment models.

Decision matrix

	Docker Compose	Kubernetes
Best for	Local dev, single-host demos, small teams	Production at any scale
Setup time	Minutes	1 hour
Provides its own PostgreSQL	Yes (bundled container)	No (bring your own)
Horizontal scaling	No	Yes
Zero-downtime upgrades	No	Yes
Typical cost baseline	Free (your hardware)	Cluster cost + Postgres cost
Docs	Docker Compose →	Kubernetes (Helm) →

For managed-service deployments — AWS EKS, GCP GKE, Azure AKS, or DigitalOcean DOKS, each paired with the provider's managed PostgreSQL (RDS, Cloud SQL, Azure Database for PostgreSQL, DO Managed Databases) — the Kubernetes guide is the base. The same Helm chart runs unchanged on every managed Kubernetes control plane, with cloud-provider-specific IAM and networking applied through your provider's standard managed-Kubernetes guidance.

What every deployment needs

Regardless of target, every DVARA deployment needs:

1. A PostgreSQL instance — the single source of truth for all configuration, audit events, and metering records. Version 14+. Schema is created automatically on first boot; point the gateway at an empty database and no manual setup is required.
2. Provider credentials — at least one LLM provider API key (OpenAI, Anthropic, Gemini, Bedrock, etc.) supplied via environment variable, vault, or the Flightdeck BYOK UI.
3. A license decision — DVARA runs with no license in the Development posture: pull the public dvara-gateway / dvara-flightdeck images and boot. Every governance engine works there. A signed DVARA_LICENSE_KEY activates the MCP and A2A planes and confers production rights and support — no image change is needed, and there is no operator-flippable bypass of the controls. See Container images & license posture.
4. A database-topology decision — by default every component talks to PostgreSQL. A data-plane pod can instead serve configuration from a signed bundle and spool audit locally, holding no database credential and continuing to serve while the control plane is down. Opt-in and reversible — see Running the data plane without a database.

See Configuration Reference for the complete property list and environment-variable mapping that applies to all targets.

What to read next

• Docker Compose setup — single-host, bundled Postgres, fastest path to a working instance
• Kubernetes (Helm) — production reference with autoscaling, PDBs, and external Postgres (works the same on EKS / GKE / AKS / DOKS)
• Configuration Reference — every property, environment variable, and default in one place