Customize Pigsty with Configuration
You can generate a configuration file with the configuration wizard. You can also write the file yourself. This guide builds an inventory in stages.
The deploy.yml playbook deploys NODE, INFRA, ETCD, MINIO, and PGSQL when the inventory defines them.
Docker, Redis, Kafka, native MySQL, JUICE, and VIBE require their own playbooks.
The procedures below show the configuration and playbooks for each stage.
Minimal Configuration
The smallest valid configuration defines admin_ip.
This is the IP address of the administration node where you installed Pigsty:
This inventory defines no deployment targets.
With this configuration, ./deploy.yml generates a self-signed certificate authority (CA) in files/pki/ca.
The CA issues certificates for the deployment.
Set region to select a software repository region.
The available values are default, china, and europe.
Add Nodes
The NODE module manages the nodes in the inventory. Add a node IP address to include that node in NODE module deployment:
These examples add two global parameters:
node_repo_modulesselects the software repositories to add.regionselects the repository region.
The NODE module uses these repositories to install the required packages. Other NODE parameters control node names, DNS, NTP, kernel parameters, tuning, monitoring, and log collection. You can use the default values for the initial deployment.
Run node.yml to apply the NODE configuration.
The deploy.yml playbook also includes this stage.
Add Infrastructure
The infrastructure supplies monitoring, alerting, dashboards, NTP, and DNS.
To deploy the INFRA module, define the infra group:
Set infra_seq to identify each INFRA node.
This identity parameter distinguishes nodes in deployments with multiple INFRA nodes.
Run infra.yml to install INFRA and NODE on 10.10.10.10:
The inventory IP address also defines the NODE deployment target. NODE tasks are idempotent: they apply the changes necessary to reach the specified configuration.
After this stage, the node has monitoring services and node monitoring. It does not yet have a PostgreSQL database service.
If you only need Grafana and Victoria monitoring, you can stop here.
The infra template supports this use.
Pigsty also supports PostgreSQL without the infrastructure through Slim Installation.
Deploy Database Cluster
To add PostgreSQL, define the PGSQL module and its ETCD dependency:
The etcd group defines a single-node etcd cluster.
The pg-meta group defines a single-node PostgreSQL cluster.
Install ETCD first. PGSQL uses ETCD for high-availability consensus. Run the module playbooks in this order:
You can also apply the core modules together with ./deploy.yml.
Before another deployment run, review the effects on existing services.
After these playbooks complete successfully, PostgreSQL is available.
The procedures use four playbooks to deploy four modules on one node:
Define Databases and Users
Define PostgreSQL databases and users in the inventory:
pg_users defines the dbuser_meta account with the example password DBUser.Meta.
pg_databases defines the meta database with the vector extension.
It also loads the optional Pigsty CMDB schema.
Replace the example password before deployment.
Database and user parameters control their properties.
If you define these parameters before deployment, pgsql.yml creates the databases and users.
For an existing cluster, use these commands to create or change users and databases:
Configure PG Version and Extensions
Pigsty supports multiple PostgreSQL major versions and 600 extensions.
The example below replaces PostgreSQL 18 with PostgreSQL 16.
This procedure recreates pg-meta; it is not an in-place version change.
Before removal, back up the cluster and confirm the target. Use check mode to examine the removal tasks:
The --check command does not perform the removal.
Complete the required removal before you recreate the cluster.
Set these parameters in the new configuration:
pg_extensionsinstallstimescaledb,postgis, andpgvectorpackages.pg_libsloads thetimescaledb,pg_stat_statements, andauto_explainlibraries.pg_databasesenablesvector,postgis, andtimescaledbin themetadatabase.
Then run the PostgreSQL deployment playbook:
Add More Nodes
Add the new node definitions to the inventory.
Run bin/node-add to configure monitoring and repositories and install the node packages.
Select the complete group or individual IP addresses:
Deploy HA PostgreSQL Cluster
Define the pg-test cluster on the three new nodes.
Set one node as the primary and two nodes as replicas:
Deploy the cluster with the PGSQL playbook or its bin/pgsql-add wrapper.
See the high-availability requirements for the ETCD topology.
Deploy Redis Cluster
Pigsty supports Redis as an optional cache for PostgreSQL applications. After you define a Redis cluster in the inventory, run the applicable command:
For Redis high availability, use cluster mode or sentinel mode. See Redis Configuration.
Deploy Silo Object Storage
The MINIO module deploys Silo object storage.
Silo implements the S3 interface and can store PostgreSQL backups.
The module, inventory group, and playbooks keep the minio name for compatibility.
Run the module playbook:
A production Silo deployment typically requires at least four nodes with four disks per node (4N/16D).
Deploy Docker Module
To run PostgreSQL tools and applications in containers, install the DOCKER module:
Use an application template to deploy the required software. For example, run this command to deploy pgAdmin:
You can also deploy Supabase with Pigsty. Supabase uses an external HA PostgreSQL cluster for its database and containers for its stateless components.
Was this page helpful?
Thanks—your feedback helps us improve this page.
What got in the way? (optional)