Infra as Code
Pigsty uses IaC and GitOps. Describe the environment in a declarative inventory. Apply it with idempotent playbooks.
Declare the target state with parameters. Playbooks can repeatedly adjust nodes to that state. This resembles Kubernetes CRDs and Operators, implemented through Ansible on physical servers and VMs.
Pigsty was designed to manage large PostgreSQL deployments. Its target was to reproduce more than 100 database clusters, PG/Redis services, and monitoring on prepared servers within ten minutes. Manual GUI operations cannot complete that work in the available time. CLI-based IaC provides precise, efficient control.
pigsty.yml describes the deployment state. Production, staging, test, and development environments use the same deployment logic. Their inventories define the differences.
Store this configuration in Git for version history and auditing. You can also store it in PostgreSQL CMDB tables as infrastructure data. Integrate either method with existing workflows.
IaC supports enterprise operators, individual developers, and smaller organizations. Default values avoid the need to understand every parameter. Start a single-node database with zero configuration. Add two IP addresses for an enterprise HA PostgreSQL cluster.
Declare Modules
This default example installs INFRA, NODE, ETCD, and PGSQL on 10.10.10.10.
Run these playbooks to install the modules:
Declare Clusters
Install PGSQL on multiple nodes to declare a PostgreSQL cluster as one service unit:
For a three-node HA cluster using streaming replication, add this definition to all.children in pigsty.yml. The three nodes must already be managed by Pigsty.
After defining the cluster, create it with playbooks:

Instance roles include primary, replica, offline, delayed, and synchronous standby. Cluster types include standby, Citus, Redis, MINIO (Silo), and Etcd.
Customize Cluster Content
Declare databases, users, services, and HBA rules inside each cluster. This example customizes the default pg-meta single-node cluster:
It declares six business databases and seven business users. It adds a standby service for reads without replication delay, additional pg_hba rules, a primary L2 VIP, and a custom backup strategy.
Declare Access Control
Declarative configuration also controls access permissions. This example customizes security for pg-meta:
The three-node crit.yml template prioritizes consistency and zero-loss failover. It enables L2 VIP and restricts database and pool listeners to loopback, internal, and VIP addresses. It enables TLS for the Patroni API and PgBouncer. HBA rules require SSL for database access. $libdir/passwordcheck in pg_libs enforces the password policy.
A separate pg-meta-delay cluster follows pg-meta with a one-hour delay for emergency recovery after data deletion.
Citus Distributed Cluster
This configuration declares a four-node Citus cluster:
Redis Clusters
These examples declare Redis primary-replica, sentinel, and Redis Cluster deployments:
ETCD Cluster
This configuration declares a three-node Etcd cluster:
MINIO (Silo) Cluster
This configuration declares a three-node Silo cluster. Inventory groups and parameters retain MINIO compatibility names:
Describe your infrastructure and clusters using declarative configuration files
Use the configure script to automatically generate recommended configuration files based on your environment.
Fine-tune Pigsty customization using configuration parameters
Use pre-made configuration templates to quickly generate configuration files adapted to your environment
Use PostgreSQL as a CMDB metabase to store Ansible inventory.
Was this page helpful?
Thanks—your feedback helps us improve this page.
What got in the way? (optional)