> For the complete documentation index, see [llms.txt](https://docs.openg2p.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openg2p.org/operations/deployment/infrastructure-setup.md). # Production The production deployment runs OpenG2P across role-specialised VMs — **Reverse Proxy**, **Compute** (Kubernetes), and **Storage** (host PostgreSQL + NFS) — with admin tools behind a Wireguard VPN and citizen-facing services on the public channel.
It comes in two configurations, sharing the **same architecture** — the difference is the number of nodes: * **Production — Minimum** (four nodes; one Reverse Proxy, one Compute, one Storage, one Backup) — pilots and small-scale production where some downtime is acceptable. The Backup node is **required for production** (installed via the separate [backup automation](/operations/deployment/infrastructure-setup/backups.md)). * **Production — High-Availability** (more nodes; HA Kubernetes control plane, redundant RPs behind a load balancer, PostgreSQL primary/replica) — large-scale or near-zero-downtime deployments. A supported scaling-up of the same architecture; manual/extension work today, not yet automated. See [OpenG2P Deployment Architecture](/operations/deployment/openg2p-deployment-model.md) for the full conceptual picture, and [Deployment](/operations/deployment.md) for choosing between sandbox and production. ## The five stages A production rollout happens in five stages. Stage 1 (Procurement) can — and should — start in parallel with Stage 2 (Provisioning), since the cert and DNS items in Stage 1 typically take **2–4 weeks** to deliver. Stages 3, 4, and 5 are strictly serial. ```mermaid flowchart LR S1["1. Procurement
compute specs · DNS · TLS cert
server access · firewall plan
2-4 weeks lead time"] S2["2. Provisioning
bring up the 4 VMs
on-prem or AWS"] S3["3. Infrastructure
RKE2, Istio, Rancher,
WG, Nginx, NFS,
host PostgreSQL"] S4["4. Environment
namespace, Istio Gateway,
commons-base + commons-services"] S5["5. Modules
per-product Helm charts
(Registry, PBMS, SPAR, …)"] S1 -. "in parallel" .-> S2 S2 --> S3 --> S4 --> S5 ``` | Stage | Page | What you produce | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1. Procurement** | [Prerequisites & Procurement](/operations/deployment/infrastructure-setup/prerequisites-procurement.md) | A confirmed shopping list — compute specs, DNS records to create, the TLS certificate, server-access plan, firewall rules. Requests have gone to your network / cert / IT team. | | **2. Provisioning** | [Provisioning](/operations/deployment/infrastructure-setup/provisioning.md) (with [AWS Provisioning](/operations/deployment/infrastructure-setup/provisioning/aws-provisioning.md) sub-page for the AWS path) | Three Ubuntu 24.04 VMs running, on one private subnet, SSH-reachable from the deployer's workstation. | | **3. Infrastructure** | [Infrastructure Automation](/operations/deployment/infrastructure-setup/production-automation.md) | The cluster platform: RKE2, Istio, Rancher (local auth), monitoring, logging, Wireguard, Nginx with customer-provided TLS, NFS server + host PostgreSQL. Admin tools reachable over the VPN. | | **4. Environment** | Run by the **same** [Infrastructure Automation](/operations/deployment/infrastructure-setup/production-automation.md#the-environment-stage) (`openg2p-prod.sh`); [Environment Setup](/operations/deployment/infrastructure-setup/environment-setup-multi-node.md) is the deep reference / standalone path | A working environment namespace with the Rancher Project, Istio Gateway, and `openg2p-commons-base` + `openg2p-commons-services` (PostgreSQL, Kafka, MinIO, Redis, Keycloak realm, Superset, eSignet, ODK, etc.) installed. Public 80/443 opened. | | **5. Modules** | Per-product deployment pages — [Registry](/products/registry/registry/deployment.md), [PBMS](/products/pbms/deployment.md), [SPAR](/products/spar/deployment.md), [G2P Bridge](/products/g2p-bridge/deployment.md) | Your chosen OpenG2P product modules installed into the environment via their own Helm charts. | {% hint style="info" %} **Stages 3 and 4 are one command.** The environment install (Stage 4) is built into the infrastructure automation — it runs as the `environment` stage at the tail of `openg2p-prod.sh`, not as a separate tool you invoke from another folder. It's listed as its own stage for clarity, and can be re-run on its own (`./openg2p-prod.sh --stage environment …`). The [Environment Setup](/operations/deployment/infrastructure-setup/environment-setup-multi-node.md) page documents the underlying `env-cluster.sh` and standalone / multi-environment use. {% endhint %} ## Ongoing operational concerns These are not deployment stages — they are continuous responsibilities that begin **before go-live** and continue throughout the system's lifetime. * [**Backups**](/operations/deployment/infrastructure-setup/backups.md) — configure pgBackRest, etcd snapshots, rancher-backup, and restic for NFS/configs. Set up the backup node, schedule the drills. Must be in place before go-live. * [**Production Best Practices**](/operations/deployment/infrastructure-setup/production.md) — hardening, HA recommendations, air-gap considerations, RBAC, image-pull policy, Nginx tuning. Apply incrementally; consult per deployment context. ## Sandbox is different For evaluation, demos, dev/QA, or small pilots, use the [Sandbox — Single-Node](/operations/deployment/single-node-automation.md) path instead. Sandbox collapses all five stages into a single VM and a pair of scripts — no separate procurement, provisioning, infrastructure, environment, or modules phases. The staged flow described above applies only to Production. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.openg2p.org/operations/deployment/infrastructure-setup.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.