Deployment

OpenG2P Deployment — choosing and running a sandbox or production deployment.

OpenG2P supports two deployment shapes. Pick the one that matches your stage, then follow that section — the prerequisites and steps differ.

	Sandbox (Single-Node)	Production
Use for	Evaluation, dev/QA, demos, pilots-on-a-budget	Pilots and production rollouts
Machines	1 VM	Minimum: 4 VMs (RP, Compute, Storage, Backup). High-Availability: more nodes of the same shape — HA control plane, redundant RPs, PG primary/replica
TLS	Self-signed local CA (built in)	Customer CA cert (commercial / sovereign)
DNS	Local — dnsmasq, *.<local_domain> (built in)	Customer DNS (admin + citizen records)
Admin access	Wireguard / VPC — private by default; optional public opt-in	Wireguard VPN + private channel
Procurement lead time	None — just a machine	Compute + certificate (2–4 weeks)

Rule of thumb. To get started quickly with a sandbox or two (dev/QA), use Single-Node. For pilots and production, use the Production path — strongly recommended. The Production path has two configurations sharing the same architecture: Minimum (a four-node setup — Reverse Proxy, Compute, Storage, and a required Backup node) and High-Availability (more nodes added for redundancy — supported architecture, not yet automated). If you do run a pilot on single-node, ensure backups are in place (data on Kubernetes-hosted PostgreSQL must be migrated to a standalone PostgreSQL server when you move to production — see the migration guide).

• Sandbox → Single-Node automation (prerequisites are included on that page)

• Production → start with Prerequisites & Procurement, then the infrastructure automation

For the conceptual picture (deployment models, architecture, channel separation), see OpenG2P Deployment Architecture.