This is the multi-page printable view of this section. .
Configuration Templates
- 1: meta
- 2: rich
- 3: slim
- 4: fat
- 5: infra
- 6: vibe
- 7: docker
- 8: pgsql
- 9: pg19
- 10: mssql
- 11: polar
- 12: ivory
- 13: agens
- 14: pgedge
- 15: mysql
- 16: pgtde
- 17: oriole
- 18: PostgreSQL Mongo Mode
- 19: ha/simu
- 20: ha/octo
- 21: ha/full
- 22: ha/safe
- 23: ha/trio
- 24: ha/dual
- 25: ha/citus
- 26: supabase
- 27: app/odoo
- 28: app/dify
- 29: app/electric
- 30: app/maybe
- 31: app/teable
- 32: app/mattermost
- 33: app/registry
- 34: app/insforge
- 35: app/hindsight
- 36: app/immich
- 37: app/jumpserver
- 38: demo/bare
- 39: demo/el
- 40: demo/debian
- 41: demo/demo
- 42: demo/kernel
- 43: demo/minio
- 44: demo/redis
- 45: demo/kafka
- 46: demo/mysql
- 47: build/oss
- 48: build/dev
- 49: demo/remote
- 50: demo/saas
- 51: demo/wool
Use -c with configure to select a template.
Specify its path relative to conf/, without the .yml suffix. For example, -c pgsql selects conf/pgsql.yml.
If you omit -c, Pigsty uses the meta template.
Development sources move kernel templates into conf/fork/, selected with -c fork/<name>. Use the actual paths in your source tree. Unreleased application changes are noted on each template page.
| Category | Templates |
|---|---|
| Solo Templates | meta, rich, fat, slim, infra, vibe, docker |
| Kernel Templates | pgsql, pg19, mssql, polar, ivory, agens, pgedge, mysql (OpenHalo), mongo, pgtde, oriole |
| HA Templates | ha/simu, ha/octo, ha/citus, ha/full, ha/safe, ha/trio, ha/dual |
| App Templates | supabase, app/odoo, app/dify, app/insforge, app/hindsight, app/electric, app/maybe, app/teable, app/mattermost, app/registry, app/immich, app/jumpserver |
| Misc Templates | demo/bare, demo/el, demo/debian, demo/demo, demo/kernel, demo/redis, demo/minio, demo/kafka, demo/mysql (native MySQL pilot), demo/remote, demo/saas, demo/wool, build/oss, build/dev |
1 - meta
The meta configuration template is the default Pigsty template. It deploys PostgreSQL on one node, which is the core function of Pigsty.
For compatibility across operating system distributions and architectures, meta installs only the minimum required software.
Overview
- Config Name:
meta - Node Count: Single node
- Description: Default single-node installation template with extensive configuration parameter descriptions and minimum required feature set.
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta,slim,fat
Usage: This is the default template. You do not need to specify -c meta during configure:
To install PostgreSQL 16 instead of the default version 18, use the -v argument in configure:
Content
Source: pigsty/conf/meta.yml
Explanation
Use meta as the default getting-started configuration for a quick initial deployment.
Use Cases:
- First-time Pigsty users
- Quick deployment in development and testing environments
- Small production environments running on a single machine
- As a base template for more complex deployments
Key Features:
- Online installation mode without building local software repository (
repo_enabled: false) - Default installs PostgreSQL 18 with
postgisandpgvectorextensions - Includes complete observability infrastructure (Grafana, VictoriaMetrics, VictoriaLogs, etc.)
- Preconfigured Docker and pgAdmin application examples
- Silo backup storage is disabled by default. Enable it if needed.
Notes:
- The default passwords are examples. You must change them before production use.
- Single-node etcd does not provide high availability. It is suitable for development and testing.
- If you need to build a local software repository, use the
richtemplate
2 - rich
The rich configuration template extends meta. Use it to try the complete set of features.
Use this template to build a local software repository, use Silo backup storage, or run Docker applications. It also provides preconfigured business databases.
Overview
- Config Name:
rich - Node Count: Single node
- Description: Feature-rich single-node configuration, adding local software repository, Silo backup, complete extensions, Docker application examples on top of
meta - OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta,slim,fat
This template’s main enhancements over meta:
- Builds local software repository (
repo_enabled: true), downloads all PG extensions - Enables single-node Silo as PostgreSQL backup storage
- Preinstalls TimescaleDB, pgvector, pg_wait_sampling and other extensions
- Includes detailed user/database/service definition comment examples
- Adds Redis primary-replica instance example
- Preconfigures pg-test three-node HA cluster configuration stub
Usage:
Content
Source: pigsty/conf/rich.yml
Explanation
The rich template provides a complete functionality showcase configuration. Use it to learn how all features work.
Use Cases:
- Offline environments requiring local software repository
- Environments needing Silo as PostgreSQL backup storage
- Pre-planning multiple business databases and users
- Running Docker applications (pgAdmin, Bytebase, etc.)
- Learners wanting to understand complete configuration parameter usage
Main Differences from meta:
- Enables local software repository building (
repo_enabled: true) - Enables Silo backup storage (compatibility preset
pgbackrest_method: minio) - Preinstalls TimescaleDB, pg_wait_sampling and other additional extensions
- Includes detailed parameter comments for understanding configuration meanings
- Preconfigures HA cluster stub configuration (pg-test)
Notes:
- Some extensions are unavailable on ARM64. Adjust the configuration as needed.
- Building local software repository requires longer time and larger disk space
- The default passwords are examples. Change them before production use.
3 - slim
The slim configuration template provides a minimal installation of a PostgreSQL high-availability cluster. It installs packages directly from the internet. It does not deploy Infra monitoring infrastructure.
If you need a database instance without a monitoring system, consider Slim Installation mode.
Overview
- Config Name:
slim - Node Count: Single node
- Description: Minimal installation template without monitoring infrastructure, installs PostgreSQL directly
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Source: pigsty/conf/slim.yml
Explanation
The slim template provides a minimal installation configuration. Use it to deploy bare PostgreSQL clusters quickly.
Use Cases:
- Only need PostgreSQL database, no monitoring system required
- Resource-limited small servers or edge devices
- Quick deployment of temporary test databases
- Already have monitoring system, only need PostgreSQL HA cluster
Key Features:
- Uses
slim.ymlplaybook instead ofdeploy.ymlfor installation - Installs software directly from internet, no local software repository
- Retains core PostgreSQL HA capability (Patroni + etcd + HAProxy)
- Minimized package downloads, faster installation
- Default uses PostgreSQL 18
Differences from meta:
slimuses the dedicatedslim.ymlplaybook. This playbook skips Infra module installation.- Faster installation, less resource usage
- Suitable for “just need a database” scenarios
Notes:
4 - fat
The fat configuration template is Pigsty’s Feature-All-Test template. It installs all extension plugins on one node. It also builds a local software repository with all extensions for PostgreSQL 14-18, which covers five major versions.
Use this configuration for testing and development. It provides a complete software package cache and supports tests of all extensions.
Overview
- Config Name:
fat - Node Count: Single node
- Description: Feature-All-Test template, installs all extensions, builds local repo with PG 14-18 all versions
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta,slim,fat
Usage:
To specify a particular PostgreSQL version:
Content
Source: pigsty/conf/fat.yml
Explanation
The fat template provides a full-featured test configuration. Use it to test completeness and build offline packages.
Key Features:
- All Extensions: Installs all categorized extension packages for PostgreSQL 18
- Multi-version Repository: Local repo contains all five major versions of PostgreSQL 14-18
- Complete Component Stack: Includes Silo backup, Docker applications, VIP, etc.
- Enterprise Components: Includes Kafka, PolarDB, IvorySQL, TigerBeetle, etc.
Repository Contents:
| Category | Description |
|---|---|
| PostgreSQL 14-18 | Five major versions’ kernels and all extensions |
| Extension Categories | time, gis, rag, fts, olap, feat, lang, type, util, func, admin, stat, sec, fdw, sim, etl |
| Enterprise Components | kafka-stack, Java Runtime, Sealos, TigerBeetle |
| Database Kernels | PolarDB, IvorySQL |
Differences from rich:
fatcontains all five versions of PostgreSQL 14-18. Therichtemplate contains only the current default version.fatcontains additional enterprise components (Kafka, PolarDB, IvorySQL, etc.)fatrequires larger disk space and longer build time
Use Cases:
- Pigsty development testing and feature validation
- Building complete multi-version offline software packages
- Testing all extension compatibility scenarios
- Enterprise environments pre-caching all software packages
Notes:
- Requires large disk space (100GB+ recommended) for storing all packages
- Building local software repository requires longer time
- Some extensions unavailable on ARM64 architecture
- The default passwords are examples. Change them before production use.
5 - infra
The infra template deploys the Pigsty monitoring infrastructure, including VictoriaMetrics, Grafana, VictoriaLogs, and Nginx.
It does not deploy PostgreSQL or etcd.
Use it as a standalone monitoring system for external PostgreSQL or RDS instances and other data sources.
Overview
- Config Name:
infra - Node Count: Single or multiple nodes
- Description: Only installs observability infrastructure, without PostgreSQL and etcd
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Source: pigsty/conf/infra.yml
Explanation
The infra template runs the monitoring infrastructure independently of database services.
Use Cases:
- Monitoring external PostgreSQL instances (RDS, self-hosted, etc.)
- Need standalone monitoring/alerting platform
- Already have PostgreSQL clusters, only need to add monitoring
- As a central console for multi-cluster monitoring
Included Components:
- VictoriaMetrics: Time series database for storing metrics
- VictoriaLogs: Log aggregation system
- VictoriaTraces: Distributed tracing system
- Grafana: Visualization dashboards
- Alertmanager: Alert management
- Nginx: Reverse proxy and web entry
Not Included:
- PostgreSQL database cluster
- etcd distributed coordination service
- Silo object storage
Monitoring External Instances:
After configuration, run pgsql-monitor.yml to add monitoring for external PostgreSQL instances:
Notes:
6 - vibe
The vibe configuration template provides a ready-to-use AI coding sandbox. It includes Code-Server (Web VS Code), JupyterLab, Claude Code observability, and Codex CLI. It also includes the JuiceFS distributed filesystem and a PostgreSQL database with many features.
Overview
- Config Name:
vibe - Node Count: Single node
- Description: VIBE AI coding sandbox with Code-Server + JupyterLab + Claude Code + Codex CLI + JuiceFS + PostgreSQL
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Source: pigsty/conf/vibe.yml
Explanation
The vibe template provides an AI coding sandbox for the web. Use your browser for development, data analysis, and AI application development.
Core Components:
| Component | Description | Access Method |
|---|---|---|
| Code-Server | Web version of VS Code, full-featured code editor | http://<ip>/code |
| JupyterLab | Interactive data science notebook, Python/SQL | http://<ip>/jupyter |
| Claude Code | AI coding runtime and observability entrypoint (claude_env customizable) | Terminal / Dashboard |
| Codex CLI | OpenAI agentic coding CLI; VIBE installs it but does not manage its configuration | Terminal |
| JuiceFS | PostgreSQL-based distributed filesystem | Mount point /fs |
| PostgreSQL 18 | Feature-rich database with pg18-main + categorized extension package groups | Port 5432 |
Node tools explicitly installed by this template (node_packages):
openssh-server,juicefs,restic,rcloneuv,opencode,golangasciinema,tmux
PostgreSQL Extensions:
This template installs PostgreSQL 18 extension groups by category:
By default, the meta database enables postgis, timescaledb, and vector. Enable other extensions as needed.
VIBE Module Components
The VIBE module provides an AI coding sandbox. The vibe.yml template explicitly enables Code-Server and Jupyter. It installs Claude Code and Codex CLI by default.
Code-Server: VS Code in browser
- Full VS Code functionality, extension support
- HTTPS access via Nginx reverse proxy
- Supports Open VSX and Microsoft extension marketplaces
- Explicit template params:
code_enabled,code_password - Optional params:
code_port,code_data,code_gallery
JupyterLab: Interactive computing environment
- Python/SQL/Markdown notebook support
- Pre-configured Python venv with data science libraries
- HTTPS access via Nginx reverse proxy
- Explicit template params:
jupyter_enabled,jupyter_password - Optional params:
jupyter_port,jupyter_data,jupyter_venv
Claude Code: AI coding assistant runtime
- Uses module default behavior to bootstrap Claude runtime
- Supports endpoint/API key overrides through
claude_env - Provides
claude-codedashboard for usage monitoring
Codex CLI: AI coding assistant
- Controlled by
codex_enabled, which defaults totrue - VIBE installs only
@openai/codex. It does not write the Codex configuration or connect Codex to the Claude Code dashboard.
JuiceFS Filesystem
This template uses JuiceFS as a distributed filesystem. It stores both metadata and data in PostgreSQL.
Architecture Features:
- Metadata Engine: Uses PostgreSQL for filesystem metadata storage
- Data Storage: Uses PostgreSQL Large Object for file data storage
- Mount Point: Default mount at
/fs(controlled byjuice_instances.jfs.path) - Monitoring Port:
9567provides Prometheus metrics
Use Cases:
- Persistent storage for code projects
- Working directory for Jupyter Notebooks
- Storage for AI models and datasets
- File sharing across instances (when scaled to multiple nodes)
Config Example:
Deployment Steps
Access Methods
After deployment, access via browser:
Use Cases
- AI App Development: Build RAG, Agent, LLM applications
- Data Science: Use JupyterLab for data analysis and visualization
- Remote Development: Setup Web IDE environment on cloud servers
- Teaching Demos: Provide consistent dev environment for students
- Rapid Prototyping: Quickly validate ideas without local env setup
- Claude Code Observability: Monitor AI coding assistant usage
Notes
- Must change passwords:
code_passwordandjupyter_passworddefaults are for testing only - Jupyter boundary: The template listens on
0.0.0.0:8888, allows any Origin, and disables XSRF checks. It relies on the token by default. Restrict the port and portal sources. Never expose Jupyter directly to the Internet. - Network security: By default, this template exposes
5432(node_firewall_public_port) and includesaddr: worldHBA. Remove these public paths for production. Add portal Basic Auth when appropriate. - Resource requirements: Recommend at least 2 cores 4GB memory, SSD disk
- Simplified architecture: This template disables HA components, including Patroni and PgBouncer. It is suitable for a single-node development environment.
- Claude API: Using Claude Code requires configuring API key in
claude_env
7 - docker
The docker template runs Pigsty in a Docker container.
It supplies the minimum single-node infrastructure and PostgreSQL components.
For full workflow details, see Docker Deployment.
Overview
- Config Name:
docker - Node Count: Single node (container runtime)
- Description: Quick-start container template using
127.0.0.1and trimmed system capabilities for Docker scenarios - OS Distro: Container image runtime (official Pigsty Docker image recommended)
- OS Arch:
x86_64,aarch64 - Related:
meta,vibe
Usage:
Content
Source: pigsty/conf/docker.yml
Explanation
Use the docker template for development and validation inside containers.
Key Features:
- Disables local repository builds with
repo_enabled: false. This reduces the build overhead inside the container. - Simplifies node behavior by disabling NTP, kernel module loading, and
/etc/hostsrewrite - Uses PostgreSQL 18 by default with a broad preset extension package bundle (
pg18-*) - Allows password access from both
intraandworldranges inpg_hba_rulesfor fast testing - Keeps optional capabilities (Code-Server, Jupyter, JuiceFS, Claude CLI) as commented settings
Notes:
- This template targets development and demonstrations. For production, restrict
pg_hba_rulesand strengthen the password policy. - Mount
/datain the container runtime to persist PostgreSQL and component data
8 - pgsql
Development sources use conf/fork/pgsql.yml; v4.5.0 uses conf/pgsql.yml, selected with -c pgsql.
The pgsql configuration template uses the native PostgreSQL kernel. This is Pigsty’s default database kernel, with stable support for PostgreSQL 14 to 18.
The current configure command also accepts version 19. PG19 remains Beta. Use the dedicated pg19 template for evaluation.
Overview
- Config Name:
pgsql - Node Count: Single node
- Description: Native PostgreSQL kernel configuration template
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
To specify a non-default PostgreSQL version (e.g., 16):
Content
Development source: conf/fork/pgsql.yml; release source: v4.5.0: conf/pgsql.yml.
Explanation
The pgsql template provides the standard kernel configuration for community-native PostgreSQL.
Version Support:
- PostgreSQL 18 (default)
- PostgreSQL 17, 16, 15, 14
- PostgreSQL 19 Beta (evaluation; use
./configure -c pg19)
Use Cases:
- Need to use the latest PostgreSQL features
- Need the widest extension support
- Standard production environment deployment
- Same functionality as
metatemplate, explicitly declaring native kernel usage
Differences from meta:
pgsqltemplate explicitly declares using native PostgreSQL kernel- Suitable for scenarios needing clear distinction between different kernel types
9 - pg19
pg19 is the single-node PostgreSQL 19 Beta evaluation template. It follows the meta topology and enables the beta repository. The local repository’s additional cache contains only core PGSQL packages. The template does not preinstall extensions.
Overview
- Config Name:
pg19 - Node Count: Single node
- PostgreSQL Version:
19Beta - Use Cases: New-version evaluation and compatibility testing
- Related:
meta,pgsql
Usage:
Content
Source: pigsty/conf/pg19.yml
Explanation
Important defaults and limitations:
node_repo_modules: node,infra,pgsql,betaobtains PG19 packages from the PGDG Beta repositoryrepo_extra_packages: [pgsql-core]limits the local repository’s additional cache to core PGSQL packages. Instances still use the role’s defaultpgsql-main pgsql-commoninstallation set.pg_extensions: []installs no extension packagespgbackrest_enabled: trueandpgbackrest_exporter_enabled: true. Thepg-metacluster retains its daily 01:00 full-backup job.- INFRA, ETCD, PGSQL, and optional pgAdmin remain available for a single-node evaluation
Use this Beta configuration for evaluation only. Do not use it as a production template. The -v 19 option on an ordinary template does not make PG19 ready for production. Validate extension compatibility, backup and recovery, and upgrade procedures separately.
10 - mssql
Development sources use conf/fork/mssql.yml; v4.5.0 uses conf/mssql.yml, selected with -c mssql.
The mssql configuration template uses Babelfish instead of native PostgreSQL, providing Microsoft SQL Server wire protocol (TDS) and T-SQL syntax compatibility. The repository provides PG17- and PG18-compatible packages; the template defaults to pg_version: 17. See the package lists for availability on each platform.
./configure -c mssql ignores -v. To use PG18, explicitly change pg_version in the generated pigsty.yml and verify that the kernel packages and extensions are available for your platform. The development path fork/mssql does not match the old-name check, so -v overrides its version.
Since v4.2, Pigsty builds Babelfish directly and does not use the WiltonDB repository. Babelfish is available on all supported Linux platforms.
For the complete tutorial, see: Babelfish (MSSQL) Kernel Guide
Overview
- Config Name:
mssql - Node Count: Single node
- Description: Babelfish (PG17) configuration template with SQL Server protocol compatibility
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Development source: conf/fork/mssql.yml; release source: v4.5.0: conf/mssql.yml.
Explanation
With the mssql template, SQL Server Management Studio (SSMS) and other SQL Server clients can connect to PostgreSQL. Babelfish provides the protocol compatibility.
Key Features:
- Uses TDS protocol (port 1433), compatible with SQL Server clients
- Supports T-SQL syntax, low migration cost
- Retains PostgreSQL’s ACID properties and extension ecosystem (the current template uses PG17)
- Supports
multi-dbandsingle-dbmigration modes - Default package set:
babelfish + pgsql-common + sqlcmd - Creates
uuid-ossp,babelfishpg_common,babelfishpg_tsql,babelfishpg_tds, andbabelfishpg_moneyby default - v4.2.0 adds full mainstream platform coverage (EL 8/9/10, Debian 12/13, Ubuntu 22/24/26;
x86_64/aarch64)
Connection Methods:
Use Cases:
- Migrating from SQL Server to PostgreSQL
- Applications needing to support both SQL Server and PostgreSQL clients
- Leveraging PostgreSQL ecosystem while maintaining T-SQL compatibility
Notes:
- The template defaults to a PostgreSQL 17-compatible kernel. After changing versions, check
pg_versionin the generated inventory and the package support matrix before deploying. - Default migration mode is
multi-db(babelfishpg_tsql.migration_mode), configurable tosingle-dbwhen needed - Some T-SQL syntax can have compatibility differences. See the Babelfish compatibility documentation.
- Must use
md5authentication method (notscram-sha-256)
11 - polar
Development sources use conf/fork/polar.yml; v4.5.0 uses conf/polar.yml, selected with -c polar.
The polar configuration template uses Alibaba Cloud’s PolarDB for PostgreSQL kernel instead of native PostgreSQL. This cloud-native kernel separates storage and compute in an architecture similar to Aurora.
For the complete tutorial, see: PolarDB for PostgreSQL (POLAR) Kernel Guide. For kernel differences and version references, see the PGSQL kernel overview.
Overview
- Config Name:
polar - Node Count: Single node
- Description: Uses PolarDB for PostgreSQL kernel
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Development source: conf/fork/polar.yml; release source: v4.5.0: conf/polar.yml.
Explanation
The polar template uses Alibaba Cloud’s open-source PolarDB for PostgreSQL kernel. The kernel provides cloud-native database capabilities.
Key Features:
- The architecture separates storage and compute. Compute and storage nodes can scale independently.
- Supports one write node and multiple read nodes. Read replicas scale in seconds.
- Compatible with PostgreSQL ecosystem, maintains SQL compatibility
- Supports shared storage scenarios, suitable for cloud environment deployment
- Default PolarDB kernel path is
/usr/polar-17 - Available extensions follow the PolarDB 17 kernel catalog. Common extensions include
pgaudit,pg_partman,pg_profile,pg_repack,pg_stat_kcache,pg_cron, andpg_hint_plan
Use Cases:
- Cloud-native scenarios requiring storage-compute separation architecture
- Read-heavy write-light workloads
- Scenarios requiring quick scaling of read replicas
- Test environments for evaluating PolarDB features
Notes:
- PolarDB is now based on PostgreSQL 17
- Replication user requires superuser privileges (different from native PostgreSQL)
- Some PostgreSQL extensions may have compatibility issues
- The current template provides packages for both
x86_64andaarch64
12 - ivory
Development sources use conf/fork/ivory.yml; v4.5.0 uses conf/ivory.yml, selected with -c ivory.
The ivory template replaces the standard PostgreSQL kernel with Highgo’s IvorySQL.
IvorySQL supports Oracle syntax and PL/SQL.
For the complete tutorial, see: IvorySQL (Oracle Compatible) Kernel Guide
Overview
- Config Name:
ivory - Node Count: Single node
- Description: Uses IvorySQL Oracle-compatible kernel
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Development source: conf/fork/ivory.yml; release source: v4.5.0: conf/ivory.yml.
Explanation
Highgo’s open-source IvorySQL kernel supplies Oracle database compatibility.
Key Features:
- Supports Oracle PL/SQL syntax
- Compatible with Oracle data types (NUMBER, VARCHAR2, etc.)
- Supports Oracle-style packages
- Retains all standard PostgreSQL functionality
Use Cases:
- Migrating from Oracle to PostgreSQL
- Applications needing both Oracle and PostgreSQL syntax support
- Leveraging PostgreSQL ecosystem while maintaining PL/SQL compatibility
- Test environments for evaluating IvorySQL features
Notes:
- IvorySQL 5 is based on PostgreSQL 18
- To use
liboracle_parser, add it toshared_preload_libraries. - In Oracle-compatible mode,
pgbackrestcan have checksum problems. PITR support is limited. - The current package matrix covers EL 8/9/10, Debian 12/13, Ubuntu 22/24/26, and both architectures
13 - agens
Development sources use conf/fork/agens.yml; v4.5.0 uses conf/agens.yml, selected with -c agens.
The agens template replaces the standard PostgreSQL kernel with AgensGraph.
It supports property graphs and Cypher queries.
For the full guide, see: AgensGraph kernel guide
Overview
- Config name:
agens - Node count: Single node
- Description: AgensGraph (PG17) graph database kernel template
- Supported OS:
el8,el9,el10,d12,d13,u22,u24,u26 - Supported arch:
x86_64,aarch64 - Related templates:
meta,pgsql
Enable with:
Template Content
Development source: conf/fork/agens.yml; release source: v4.5.0: conf/agens.yml.
Notes
The agens template sets pg_mode: agens in the pg-meta cluster.
It installs the agensgraph kernel package instead of standard PostgreSQL.
Key features:
- Property graph model support (Vertex / Edge)
- Cypher query syntax, can be combined with SQL
- Compatible with PostgreSQL ecosystem and standard operations
- Based on PostgreSQL 17-compatible kernel by default
Typical use cases:
- Graph relationship analysis and path queries
- Social graph, risk linkage, knowledge graph scenarios
- Workloads requiring graph queries within PostgreSQL operations
Caveats:
- Current AgensGraph template is pinned to
pg_version: 17 - The default topology has one node for validation. For production, plan and extend it for high availability.
- Follow the official AgensGraph documentation for graph schemas and Cypher semantics.
14 - pgedge
Development sources use conf/fork/pgedge.yml; v4.5.0 uses conf/pgedge.yml, selected with -c pgedge.
The pgedge configuration template uses the pgEdge kernel instead of native PostgreSQL. The kernel provides distributed, multi-master capabilities for edge deployments.
For the full guide, see: pgEdge kernel guide. For kernel differences and version references, see the PGSQL kernel overview.
Overview
- Config name:
pgedge - Node count: Single node
- Description: pgEdge (PG18) distributed kernel template
- Supported OS:
d12,d13,u22,u24,u26for PG18 packages. For EL/RPM platforms, check current PGSQL repository availability forpgedge_18. - Supported arch:
x86_64,aarch64 - Related templates:
meta,pgsql
Enable with:
Template Content
Development source: conf/fork/pgedge.yml; release source: v4.5.0: conf/pgedge.yml.
Notes
The pgedge template enables pg_mode: pgedge in pg-meta. It pre-installs pgEdge core extensions for logical replication and edge distribution.
Key features:
- Uses the
pgedgekernel package (PG15/16/17/18 compatible, default PG18) - The
pgedge-$vkernel package includesspock,snowflake, andlolor. The template creates these extensions in themetadatabase by default. - Preloads
spockandlolorfor multi-master setup readiness - Keeps Pigsty standard backup, monitoring, and operations workflow
Typical use cases:
- Multi-region edge deployment with nearby writes
- Multi-master logical replication with conflict handling
- Single-node validation before distributed rollout
Caveats:
- Use the current template to validate the kernel on one node. For production multi-master deployment, explicitly plan the topology and replication strategy.
- Default is
pg_version: 18; keep consistent with target cluster versions - Evaluate latency and conflict policy before cross-region replication
15 - mysql
Development sources use conf/fork/mysql.yml; v4.5.0 uses conf/mysql.yml, selected with -c mysql.
The mysql configuration template uses the OpenHalo database kernel instead of native PostgreSQL. OpenHalo provides MySQL wire protocol and SQL syntax compatibility.
Overview
- Config Name:
mysql - Node Count: Single node
- Description: OpenHalo MySQL-compatible kernel configuration
- OS Distro: EL 8/9/10, Debian 12/13, Ubuntu 22/24/26
- OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Development source: conf/fork/mysql.yml; release source: v4.5.0: conf/mysql.yml.
Explanation
The mysql template uses the OpenHalo kernel. You can connect to PostgreSQL with MySQL client tools.
Key Features:
- Uses MySQL protocol (port 3306), compatible with MySQL clients
- Supports a subset of MySQL SQL syntax
- Retains PostgreSQL’s ACID properties and storage engine
- Supports both PostgreSQL and MySQL protocol connections simultaneously
Connection Methods:
Use Cases:
- Migrating from MySQL to PostgreSQL
- Applications needing to support both MySQL and PostgreSQL clients
- Leveraging PostgreSQL ecosystem while maintaining MySQL compatibility
Notes:
- OpenHalo is based on PostgreSQL 14. It does not support features from later versions.
- Some MySQL syntax may have compatibility differences
- The current
openhalopackage alias covers Pigsty’s supported Linux platforms on both architectures. Installation still depends on the repository index for the target platform.
16 - pgtde
Development sources use conf/fork/pgtde.yml; v4.5.0 uses conf/pgtde.yml, selected with -c pgtde.
The pgtde configuration template uses the Percona PostgreSQL database kernel. This kernel provides Transparent Data Encryption (TDE).
Overview
- Config Name:
pgtde - Node Count: Single node
- Description: Percona PostgreSQL transparent data encryption configuration
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Development source: conf/fork/pgtde.yml; release source: v4.5.0: conf/pgtde.yml.
Explanation
The pgtde template selects pg_mode: pgtde and installs the pgtde package
alias. Pigsty links the private /usr/pgtde-$v prefix (currently
/usr/pgtde-18) to its stable /usr/pgsql entry point.
Key Features:
- Transparent Data Encryption: The kernel automatically encrypts data on disk. Applications do not need to manage this encryption.
- Key Management: Supports local keys and external Key Management Systems (KMS)
- Table-level Encryption: Selectively encrypt sensitive tables
- Full Compatibility: Fully compatible with native PostgreSQL
Use Cases:
- Meeting data security compliance requirements (e.g., PCI-DSS, HIPAA)
- Storing sensitive data (e.g., personal information, financial data)
- Scenarios requiring data-at-rest encryption
- Enterprise environments with strict data security requirements
Usage:
Notes:
- Percona PostgreSQL is based on PostgreSQL 18
- Encryption adds some performance overhead, typically 5-15%.
- Encryption keys must be properly managed
- Both
x86_64andaarch64packages are available on the listed distributions
17 - oriole
Development sources use conf/fork/oriole.yml; v4.5.0 uses conf/oriole.yml, selected with -c oriole.
The oriole configuration template uses the OrioleDB storage engine instead of PostgreSQL’s default Heap storage. It stores older row versions in UNDO logs, reducing bloat in primary storage.
Overview
- Config Name:
oriole - Node Count: Single node
- Description: OrioleDB storage engine configuration
- PostgreSQL Major:
16,17, or18 - OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Development source: conf/fork/oriole.yml; release source: v4.5.0: conf/oriole.yml.
Explanation
The oriole template enables the OrioleDB storage engine. See the kernel guide for its design.
Key Features:
- Version Management: Stores older MVCC versions in UNDO logs to reduce bloat in primary storage
- No VACUUM Required: Eliminates performance jitter from autovacuum
- Row-level WAL: More efficient logging and replication
- Compressed Storage: Built-in data compression, reduces storage space
Use Cases:
- High-frequency update OLTP workloads
- Applications sensitive to write latency
- Need for stable response times (eliminates VACUUM impact)
- Large tables with frequent updates causing bloat
Usage:
Notes:
- OrioleDB supports PostgreSQL 16, 17, and 18. The template defaults to PG18. To select a major version, use
-v 16,-v 17, or-v 18. - Need to add
orioledbtoshared_preload_libraries - Some PostgreSQL features may not be fully supported
- Use the matching OrioleDB packages for the selected PostgreSQL major and OS architecture
18 - PostgreSQL Mongo Mode
Development sources use conf/fork/mongo.yml; v4.5.0 uses conf/mongo.yml, selected with -c mongo.
The mongo configuration template is a PostgreSQL deployment mode, not an independent Pigsty module. It combines:
- PostgreSQL 18 managed by the standard
PGSQLmodule - The
documentdbextension and its required preload libraries - A stateless FerretDB proxy deployed with Pigsty’s Docker APP workflow
PostgreSQL manages all data, high availability, backups, monitoring, and the database lifecycle. FerretDB provides only the MongoDB wire-compatible endpoint.
Quick Start
The default template is a single-node deployment on 10.10.10.10. FerretDB listens on loopback by default.
Install mongosh separately if it is not already available, or use another MongoDB-compatible client.
The template declares a dedicated mongod PostgreSQL login. FerretDB authentication is enabled. MongoDB authorization roles are not implemented. PostgreSQL remains the security boundary.
Architecture
| Layer | Implementation | Responsibility |
|---|---|---|
| Data | PostgreSQL + DocumentDB | Durable storage, transactions, HA, PITR, ACL, monitoring |
| Protocol | FerretDB Docker APP | Stateless MongoDB wire compatibility |
| Access | 127.0.0.1:27017 by default | Local MongoDB client endpoint |
The container connects to Pigsty’s local primary service on port 5436 through host.docker.internal. The default Mongo endpoint is not exposed to the network. Change FERRETDB_BIND_ADDR only if you need remote access.
Configuration
Development source: conf/fork/mongo.yml; release source: v4.5.0: conf/mongo.yml.
FerretDB settings are ordinary APP overrides under apps.ferretdb.conf:
Use the standard PostgreSQL parameters, playbooks, dashboards, and administration procedures for the backend cluster. There are no mongo_* inventory parameters or standalone mongo.yml playbook.
Optional HA Topology
The template contains a commented pg-mongo example for three PostgreSQL/FerretDB nodes. Uncomment that block and the two additional etcd members when needed.
In HA mode, each FerretDB container binds {{ inventory_hostname }}:27018. HAProxy exposes all three backends through the floating endpoint 10.10.10.4:27017 (mongo.pigsty). Patroni continues to handle PostgreSQL failover. FerretDB remains stateless.
Notes
- The template includes development-friendly HBA examples; tighten them for production.
- Client-side MongoDB TLS is not enabled by default.
- Monitor the backend with the standard PostgreSQL and Docker dashboards. There is no separate FERRET module or dedicated module dashboard.
- Repeat an authenticated CRUD smoke test after upgrading FerretDB or DocumentDB.
19 - ha/simu
The ha/simu configuration template simulates a production environment with 20 nodes. It requires a powerful host machine.
Overview
- Config Name:
ha/simu - Node Count: 20 nodes,
pigsty/vagrant/spec/simu.rb - Description: 20-node production environment simulation, requires powerful host machine
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64
Usage:
Content
Source: pigsty/conf/ha/simu.yml
Explanation
The ha/simu template provides a large-scale production environment simulation. Use it to test and validate complex scenarios.
Architecture:
- 2-node HA INFRA (monitoring/alerting/Nginx/DNS)
- 5-node HA ETCD and MINIO (Silo, multi-disk)
- 2-node Proxy (HAProxy + Keepalived VIP)
- Multiple PostgreSQL clusters:
- pg-meta: 2-node HA
- pg-v14~v18: Single-node multi-version testing
- pg-pitr: Single-node PITR testing
- pg-test: 4-node HA
- pg-src/pg-dst: 3+2 node replication testing
- pg-citus: 10-node distributed cluster
- Multiple Redis modes: primary-replica, sentinel, cluster
Use Cases:
- Large-scale deployment testing and validation
- High availability failover drills
- Performance benchmarking
- New feature preview and evaluation
Notes:
- Requires powerful host machine (64GB+ RAM recommended)
- Uses Vagrant virtual machines for simulation
20 - ha/octo
ha/octo builds a compact high-availability simulation with the first eight nodes from vagrant/spec/deci.rb. It exercises co-located modules, VIPs, remote backup, and larger membership counts. Do not use it directly as a production blueprint without reviewing capacity, security, and failure domains.
Overview
- Config name:
ha/octo - Node addresses:
10.10.10.10through10.10.10.17 - INFRA: 3 nodes. Only the first builds and serves the local repository. As the comments describe, Docker can be installed separately on all three nodes.
- ETCD: 5 nodes on the last five hosts
- Object storage: one eight-node, single-drive cluster. The template does not override
minio_type. Thus, deployment and removal both default to Silo. Before removal, verify this value, the exact target, and the data paths. pg-meta: 3-node PostgreSQL cluster with VIP10.10.10.2/24pg-test: 5-node PostgreSQL cluster whose final instance has theofflinerole, with VIP10.10.10.3/24- Backup: uses the object-storage repository through
sss.pigsty:9002and also retains a local repository
This template depends on fixed eight-node addresses and VIPs. For another environment, update the host addresses, VIPs, interfaces, DNS, and repository node together. Also change every public example credential.
Content
Source: pigsty/conf/ha/octo.yml
Explanation
- The three INFRA nodes and five etcd nodes are separate sets. The
pg-metaandpg-testPostgreSQL clusters are co-located with those two sets respectively. - Object storage spans all eight nodes. It exposes
sss.pigstythrough Keepalived VIP10.10.10.9and HAProxy port9002. Silo is the current default engine. The module and variables retainminio_*names for compatibility. pg-metatakes one full backup daily.pg-testtakes a weekly full backup and incremental backups on the remaining days. Both clusters write to the encrypted S3 pgBackRest repository.- The two INFRA replicas with
repo_enabled: falsedo not build local repositories. Every node still installs packages from the first node’slocalrepository. - The final section of the template contains database, Grafana, Patroni, HAProxy, Silo, and etcd passwords. These passwords are suitable only for a disposable simulation. You must rotate all these passwords in real environments.
For a conventional minimal HA deployment, prefer ha/trio. For a larger full-scenario simulation, see ha/simu.
21 - ha/full
The ha/full template defines the recommended Pigsty sandbox.
It deploys two PostgreSQL clusters on four nodes for tests and feature demonstrations.
Most Pigsty tutorials and examples are based on this template’s sandbox environment.
Overview
- Config Name:
ha/full - Node Count: Four nodes
- Description: Four-node complete feature demonstration environment with two PostgreSQL clusters, Silo, Redis, etc.
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
ha/trio,ha/safe,demo/demo
Usage:
After configuration, modify the IP addresses of the other three nodes.
Content
Source: pigsty/conf/ha/full.yml
Explanation
The ha/full template shows how the Pigsty components work together.
Components Overview:
| Component | Node Distribution | Description |
|---|---|---|
| INFRA | Node 1 | Monitoring/Alerting/Nginx/DNS |
| ETCD | Node 1 | DCS Service |
| Silo | Node 1 | S3-compatible Storage |
| pg-meta | Node 1 | Single-node PostgreSQL |
| pg-test | Nodes 2-4 | Three-node HA PostgreSQL |
| redis-ms | Node 1 | Redis Primary-Replica Mode |
| redis-meta | Node 2 | Redis Sentinel Mode |
| redis-test | Nodes 3-4 | Redis Native Cluster Mode |
Use Cases:
- Pigsty feature demonstration and learning
- Development testing environments
- Evaluating HA architecture
- Comparing different Redis modes
Differences from ha/trio:
- Added second PostgreSQL cluster (pg-test)
- Added three Redis cluster mode examples
- Infrastructure uses single node (instead of three nodes)
Notes:
22 - ha/safe
ha/safe uses a three-node high-availability topology. It demonstrates TLS, client certificates, password checks, backup encryption, the CRIT parameter template, and related security settings. Customize this configuration example for your environment. The template does not have compliance certification.
Overview
- Configuration:
ha/safe - Nodes: 3 INFRA, etcd, and PostgreSQL nodes; optional delayed replica
- Operating systems:
el8,el9,el10,d12,d13,u22,u24,u26 - Architecture:
x86_64; some security extensions do not have ARM64 packages - Related configurations:
ha/trio,ha/full
Generate the configuration:
-g randomizes only credentials recognized by the configuration wizard. You must still replace Silo users, the pgBackRest cipher_pass, and other template example values.
Hardening Controls
| Setting | Template Behavior | Boundary and Follow-up |
|---|---|---|
| PostgreSQL HBA | Main TCP rules use ssl; public administrator access uses cert | Local ident and selected localhost pwd rules remain |
| PgBouncer | pgbouncer_sslmode: require | Clients must still verify the server certificate where required |
| Patroni | REST API uses HTTPS and a constrained listen address | Basic Auth remains; rotate the password |
| Password check | $libdir/passwordcheck_cracklib is preloaded through pg_libs | Affects only newly set or changed passwords |
| Account lifetime | Built-in and example application users set expire_in: 7300 | Twenty years is not a rotation policy; shorten it to organizational requirements |
| Listen addresses | PostgreSQL is limited to ${ip},${vip},${lo} | Firewalls and HBA are still required |
| Backup | Uses Silo with AES-256-CBC | pgBR.${pg_cluster} is a predictable example and must be replaced |
| PostgreSQL parameters | pg-meta uses crit.yml | Strict synchronous mode can block writes without a synchronous replica |
| Logging | CRIT logs connection and disconnection events | Fine-grained SQL auditing requires explicit pgaudit configuration |
| Security extensions | Installs passwordcheck_cracklib, credcheck, pgaudit, and related packages | Installation does not preload, create, or configure an extension |
| Delayed replica | Provides a commented one-hour delayed-cluster example | Not created by default; enable it explicitly |
Preflight Checklist
- Replace every public example credential, especially
minio_users,pgbackrest_repo, application users, and API passwords. - Confirm that the three nodes occupy independent failure domains. Update the IPs, VIP, and domains for the target network.
- Configure database clients with
sslmode=verify-fulland a trusted CA. - Confirm that the availability impact of strict synchronous mode meets application requirements.
- Preload and configure
pgaudit,credcheck, and other extensions as required. - Check extension package availability on ARM64.
- Test backup recovery, failover, and certificate verification.
See Security Model, Authentication, Encrypted Communication, and Data Security for the underlying mechanisms.
Configuration
Source: pigsty/conf/ha/safe.yml
23 - ha/trio
Three nodes is the minimum scale for majority-based high availability. The ha/trio template distributes INFRA, ETCD, PGSQL, and Silo across three servers. PostgreSQL, ETCD, and object storage continue serving when one server is unavailable.
Overview
- Config Name:
ha/trio - Node Count: Three nodes
- Description: Three-node standard HA architecture with a three-node, single-drive Silo cluster and one HA S3 endpoint
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
ha/dual,ha/full,ha/safe
Usage:
After configuration, modify placeholder IPs 10.10.10.11 and 10.10.10.12 to actual node IP addresses.
Content
Source: pigsty/conf/ha/trio.yml
Explanation
The ha/trio template provides the standard HA configuration in Pigsty. It supports automatic failover.
Architecture:
- Three-node INFRA: Distributed deployment of VictoriaMetrics/Grafana/Nginx
- Three-node ETCD: DCS majority election, tolerates single-point failure
- Three-node PostgreSQL: One primary, two replicas, automatic failover
- Three-node Silo: One data path per node, using EC:1 by default (two data shards and one parity shard)
- HA S3 endpoint: Keepalived VIP
10.10.10.9with HAProxy listening on9002on all three nodes
HA Guarantees:
- Three-node ETCD tolerates one node failure, maintains majority
- PostgreSQL primary failure triggers automatic Patroni election for new primary
- The L2 VIP follows the primary. Applications do not need connection configuration changes.
- Silo retains read and write quorum while one node or one data drive is unavailable
sss.pigstyresolves to the object-storage VIP. The pgBackRest andmcliclients usehttps://sss.pigsty:9002.
Object Storage:
minio_data: /data/miniois a filesystem directory, not a raw device such as/dev/sdb.- Distributed Silo rejects data paths on the root filesystem.
/data/miniomust reside on a separately mounted/datafilesystem or be a mount point itself. - The backing storage may be a local disk, cloud volume, separate partition, or LVM logical volume. For production, prefer dedicated persistent drives of similar capacity on all three nodes.
- Use
findmnt -T /data/minioto inspect the actual mount. A result that still points to/means the path is only a directory on the root drive. - The three-node, single-drive topology provides about two-thirds raw capacity efficiency. This topology provides compact HA. For greater capacity, throughput, and drive redundancy, use a multi-node, multi-drive topology.
- A single-node object-storage pool cannot be converted in place by adding two members. Create a new three-node cluster and migrate the objects instead.
The template’s S3 API endpoint is highly available. The Portal administration UI still connects to port 9001 on the first node. It does not use this API HA path.
Use Cases:
- Minimum HA deployment for production environments
- Critical business requiring automatic failover
- Foundation architecture for larger scale deployments
Extension Suggestions:
24 - ha/dual
The ha/dual template deploys one primary and one standby on two nodes.
This Semi-HA configuration provides limited failover when only two servers are available.
Overview
- Config Name:
ha/dual - Node Count: Two nodes
- Description: Two-node limited HA deployment, tolerates specific server failure
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
ha/trio,slim
Usage:
After configuration, replace 10.10.10.11 with the standby node’s actual IP address.
Content
Source: pigsty/conf/ha/dual.yml
Explanation
The ha/dual template supplies limited high availability with two nodes.
Architecture:
- Node A (10.10.10.10): Admin node, runs Infra + etcd + PostgreSQL replica
- Node B (10.10.10.11): Data node, runs PostgreSQL primary only
Failure Scenario Analysis:
| Failed Node | Impact | Auto Recovery |
|---|---|---|
| Node B down | Primary switches to Node A | Auto |
| Node A etcd down | Primary continues running (no DCS) | Manual |
| Node A pgsql down | Primary continues running | Manual |
| Node A complete failure | Primary degrades to standalone | Manual |
Use Cases:
- Budget-limited environments with only two servers
- Acceptable that some failure scenarios need manual intervention
- Transitional solution before upgrading to three-node HA
Notes:
- Full HA requires at least three nodes because the DCS requires a majority.
- Expand to three nodes as soon as your resources permit it.
- L2 VIP requires network environment support (same broadcast domain)
25 - ha/citus
The ha/citus template deploys a Citus distributed PostgreSQL cluster.
It has 1 infrastructure node, 1 coordinator group, and 5 worker groups.
The coordinator and worker groups contain 12 Citus nodes in total.
The cluster distributes data into shards and supports horizontal scaling.
Overview
- Config Name:
ha/citus - Node Count: 13 nodes (1 infra + 1 coordinator×2 + 5 workers×2)
- Description: Citus distributed PostgreSQL HA cluster
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64 - Related:
meta,ha/trio
Usage:
Note: 13-node template, modify IP addresses after generation
Content
Source: pigsty/conf/ha/citus.yml
Topology
| Cluster | Nodes | IP Addresses | VIP | Role |
|---|---|---|---|---|
| pg-meta | 1 | 10.10.10.10 | - | Infra + CMDB |
| pg-citus1 | 2 | 10.10.10.21, 22 | 10.10.10.29 | Coordinator (group 0) |
| pg-citus2 | 2 | 10.10.10.31, 32 | 10.10.10.39 | Worker (group 1) |
| pg-citus3 | 2 | 10.10.10.41, 42 | 10.10.10.49 | Worker (group 2) |
| pg-citus4 | 2 | 10.10.10.51, 52 | 10.10.10.59 | Worker (group 3) |
| pg-citus5 | 2 | 10.10.10.61, 62 | 10.10.10.69 | Worker (group 4) |
| pg-citus6 | 2 | 10.10.10.71, 72 | 10.10.10.79 | Worker (group 5) |
Architecture:
- pg-meta: Infra node running Grafana, VictoriaMetrics, etcd, plus a standalone CMDB
- pg-citus1: Coordinator group 0 with 1 primary and 1 replica. It receives queries and routes them to workers.
- pg-citus2~6: Worker groups 1~5 store sharded data. Patroni manages 1 primary and 1 replica in each group.
- VIP: Each group has L2 VIP managed by
vip-managerfor transparent failover
Explanation
Use ha/citus to deploy a production Citus cluster that can scale across multiple worker groups.
Key Features:
- Horizontal Scaling: 5 worker groups for linear storage/compute scaling
- High Availability: Each group with 1 primary + 1 replica, auto-failover
- L2 VIP: Virtual IP per group, transparent failover to clients
- SSL Encryption: Inter-node communication uses SSL certificates
- Transparent Sharding: Data auto-distributed across workers
Pre-installed Extensions:
Security:
pg_dbsu_passwordenabled for Citus inter-node communication- HBA rules require SSL authentication
- Inter-node uses certificate verification:
sslmode=verify-full
Deployment
Verify after deployment:
Examples
Create Distributed Table:
Create Reference Table (replicated to all nodes):
Use Cases
- Multi-tenant SaaS: Shard by tenant_id for data isolation and parallel queries
- Real-time Analytics: Large-scale event data aggregation
- Timeseries Data: Combine with TimescaleDB for massive timeseries
- Horizontal Scaling: When single-table data exceeds single-node capacity
Notes
- PostgreSQL Version: Citus supports PG 14~18, this template defaults to PG18
- Distribution Column: Select this column for the workload, typically tenant_id or timestamp. This choice is critical for performance.
- Cross-shard Limits: Foreign keys must include the distribution column. Some DDL operations also have restrictions.
- Network:
pg_vip_interfacedefaults toauto. For unusual network environments, explicitly select an interface. - Architecture: Citus extension does not support ARM64
26 - supabase
The supabase template provides a reference configuration to self-host Supabase. It uses PostgreSQL managed by Pigsty for the underlying storage.
For more details, see Supabase Self-Hosting Tutorial
Overview
- Config Name:
supabase - Node Count: Single node
- Description: Self-host Supabase using Pigsty-managed PostgreSQL
- OS Distro:
el8,el9,d12,u22,u24,u26 - OS Arch:
x86_64,aarch64 - PostgreSQL:
15,16,17,18(template default:18) - Supabase: use the matching application image set
- API Gateway: Kong by default
- Related:
meta,rich
Usage:
Content
Source: conf/supabase.yml, used with app/supabase/ from the same version.
Development configuration preview: Supabase 0.8.2 has no complete public deployment entry point
This configuration requires the matching development application files, database baseline, and migration scripts. Do not use it alone to replace stable configuration. See the application guide for gateway and upgrade differences.
Installation Demo
demo/supabase.cast — /demo/supabase.cast
Explanation
The supabase template provides a complete self-hosted Supabase configuration. Run this open-source Firebase alternative on your own infrastructure.
Architecture:
- PostgreSQL: Production-grade Pigsty-managed PostgreSQL (with HA support)
- Docker Containers: Supabase stateless services (Auth, Storage, Realtime, Edge Functions, etc.)
- API Gateway: The
kongservice provides HTTP port8000; the development version switches to Envoy - Silo: S3-compatible object storage deployed by the MINIO module for file storage and PostgreSQL backup
- Nginx: Reverse proxy and HTTPS termination
Key Features:
- Uses Pigsty-managed PostgreSQL instead of Supabase’s built-in database container
- Defaults to external PG18
- Supports PostgreSQL high availability (can be expanded to three-node cluster)
- Installs all Supabase-required extensions (pg_net, pgjwt, pg_graphql, vector, etc.)
- Stores internal analytics data in the dedicated
_supabasedatabase and advances processing with the scheduledsupa-kicktask - Integrated Silo object storage for file uploads and backups
- HTTPS support with Let’s Encrypt automatic certificates
Deployment Steps:
Access:
Use Cases:
- Need to self-host BaaS (Backend as a Service) platform
- Want full control over data and infrastructure
- Need enterprise-grade PostgreSQL HA and backups
- Compliance or cost concerns with Supabase cloud service
Notes:
- Must change JWT_SECRET: Use a random string with at least 32 characters. Regenerate ANON_KEY and SERVICE_ROLE_KEY.
- Configure proper domain names (
SITE_URL,API_EXTERNAL_URL) - Production environments should enable HTTPS (can use certbot for auto certificates)
- Docker networks need PostgreSQL access. The template uses
172.17.0.0/16in Docker HBA rules; adjust it to the actual container network. - Check migration steps for the target version before upgrading. Do not replay the fresh-install baseline
files/supabase.sqlon an existing database.
27 - app/odoo
The app/odoo template provides a reference configuration to self-host Odoo Community 19. It uses PostgreSQL managed by Pigsty.
For more details, see Odoo Deployment Tutorial
Overview
- Config Name:
app/odoo - Node Count: Single node
- Description: Deploy Odoo ERP using Pigsty-managed PostgreSQL
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Source: pigsty/conf/app/odoo.yml
Explanation
This single-node template runs Odoo Community 19 in Docker and uses Pigsty-managed PostgreSQL.
Key Features:
- Uses the Odoo
19.0image and PostgreSQL 18, with a dedicated role, database, andunaccent/pg_trgmextensions - Publishes port 8069 on all host interfaces, supporting direct access and the Nginx portal
- Stores filestore data in
/data/odoo/webdataand addons in/data/odoo/addons
Access:
Point odoo.pigsty to the Nginx host. The initial application login is admin / admin; change the password at first login.
Notes:
- Change the database password and
ODOO_ADMIN_PASSWORDbefore deployment; the master password is separate from the application login ./app.ymlinitializes the existing empty database before starting the web container; the database manager is disabled- Set
ODOO_PORTto the published port number; update the Nginxendpointport if you change it - Use
ODOO_PROXY_MODE=truefor proxy access andfalsefor direct access only; use HTTPS in production - Set data directory ownership to uid=100, gid=101
- Manage filestore and addon backups yourself with Restic or PGFS
28 - app/dify
The app/dify template deploys the Dify AI application development platform.
It uses Pigsty-managed PostgreSQL and pgvector for vector storage.
For more details, see Dify Deployment Tutorial
Overview
- Config Name:
app/dify - Node Count: Single node
- Description: Deploy Dify using Pigsty-managed PostgreSQL
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Source: pigsty/conf/app/dify.yml
Explanation
The app/dify template supplies the Dify deployment configuration.
The current image is Dify v1.17.1; basic functionality was validated on Linux amd64 with PostgreSQL 18.6 on 2026-10-08.
What is Dify:
- Open-source LLM application development platform
- Supports RAG, Agent, Workflow and other AI application modes
- Provides visual Prompt orchestration and application building interface
- Supports multiple LLM backends (OpenAI, Claude, local models, etc.)
Key Features:
- Uses Pigsty-managed PostgreSQL instead of Dify’s built-in database
- Uses pgvector as vector storage (replaces Weaviate/Qdrant)
- Enables the
collaborationCompose profile and WebSocket sidecar - Supports HTTPS and custom domain names
- API and plugin files use
/data/dify; Redis, Sandbox dependencies, and Agent named volumes also need backups
Access:
Use Cases:
- Enterprise internal AI application development platform
- RAG knowledge base Q&A systems
- LLM-driven automated workflows
- AI Agent development and deployment
Notes:
- Replace
SECRET_KEYand the threeDIFY_AGENT_*development secrets; see the deployment checklist. - Dify v1.16 and later support PostgreSQL 18’s
uuidv7()without a local migration patch. - Configure LLM API keys (e.g., OpenAI API Key)
- Permit PostgreSQL access from the Docker networks. The template supplies an HBA rule for
172.16.0.0/12. - Configure a proxy if necessary to speed up Python package downloads.
29 - app/electric
The app/electric template deploys the Electric SQL synchronization service.
Electric synchronizes data from PostgreSQL to clients in real time.
The preview below includes unreleased application-template updates. See the Electric application guide for port, metrics, and cache requirements.
Overview
- Config Name:
app/electric - Node Count: Single node
- Description: Deploy Electric real-time sync using Pigsty-managed PostgreSQL
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Source: pigsty/conf/app/electric.yml
Development configuration preview: requires matching Electric Compose changes
This configuration separates listening and published ports and sets persistent storage parameters. Update Compose together with it.
Development Configuration Explained
The following describes the preview above and its matching Compose file.
What is Electric:
- PostgreSQL to client real-time data sync service
- Supports Local-first application architecture
- Real-time syncs data changes via logical replication
- Provides HTTP API for frontend application consumption
Key Features:
- Uses Pigsty-managed PostgreSQL as data source
- Captures data changes via Logical Replication
- Supports SSL encrypted connections
- Persists shape metadata and logs in the
electric-datanamed volume - Optional Prometheus metrics endpoint, disabled by default; enable only after configuring regular scraping
Access:
Use Cases:
- Building Local-first applications
- Real-time data sync to clients
- Mobile and PWA data synchronization
- Real-time updates for collaborative applications
Notes:
- Give the Electric user
replicationpermission. - Enable PostgreSQL logical replication.
- For production, use SSL connections. The template sets
sslmode=require. - The container listens on
ELECTRIC_PORT=3000; the host publishesELECTRIC_PUBLISH_PORT=8002. - Storage defaults to
ELECTRIC_STORAGE=FAST_FILE, with the cache volume mounted at/var/lib/electric. ELECTRIC_INSECURE=trueis suitable only for trusted development networks. Disable it and setELECTRIC_SECRETbefore public exposure.- The metrics port is neither enabled nor published. If enabled, scrape it continuously to avoid accumulation of unconsumed metrics.
30 - app/maybe
The app/maybe template deploys Maybe, an open-source personal finance management system.
It uses Pigsty-managed PostgreSQL as its database.
The upstream repository is archived. The template retains the ghcr.io/maybe-finance/maybe:stable channel for existing deployments; the source validation snapshot is v0.6.0. stable does not imply ongoing maintenance releases. See the Maybe application guide.
Overview
- Config Name:
app/maybe - Node Count: Single node
- Description: Deploy Maybe finance management using Pigsty-managed PostgreSQL
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Source: pigsty/conf/app/maybe.yml
Explanation
Use app/maybe to configure and deploy the Maybe finance management system.
What is Maybe:
- Open-source personal and family finance management system
- Supports multi-account, multi-currency asset tracking
- Provides investment portfolio analysis and net worth calculation
- Web interface for finance management
Key Features:
- Uses Pigsty-managed PostgreSQL instead of Maybe’s built-in database
- Data persisted to independent directory
/data/maybe - Supports HTTPS and custom domain names
- Multi-user permission management
Access:
Use Cases:
- Personal or family finance management
- Investment portfolio tracking and analysis
- Multi-account asset aggregation
- Alternative to commercial services like Mint, YNAB
Notes:
- Replace
SECRET_KEY_BASE. Generate a value withopenssl rand -hex 64. - On the first visit, register an administration account.
- Optionally configure Synth API for stock price data
31 - app/teable
The app/teable template provides a reference configuration for the Teable open-source no-code database. It uses PostgreSQL managed by Pigsty.
The cache settings below require the matching development Compose file. If your Compose file does not include Redis, provide a separate cache service as described in the Teable application guide.
Overview
- Config Name:
app/teable - Node Count: Single node
- Description: Deploy Teable using Pigsty-managed PostgreSQL
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Source: pigsty/conf/app/teable.yml
Development configuration preview: requires Compose with the Redis service
Explanation
The app/teable template provides one-click deployment of the Teable open-source no-code database.
What is Teable:
- Open-source Airtable alternative
- No-code database built on PostgreSQL
- Supports table, kanban, calendar, form, and other views
- Provides API and automation workflows
Key Features:
- Uses Pigsty-managed PostgreSQL as underlying storage
- Data is stored in real PostgreSQL tables
- Supports direct SQL queries
- Can integrate with other PostgreSQL tools and extensions
- Development Compose includes authenticated Redis (default
redis:7-alpine) with a persistent AOF volume and no published Redis port - Development Compose waits for Redis readiness before starting the application and checks the backend
/healthendpoint
Access:
Use Cases:
- Need Airtable-like functionality but want to self-host
- Team collaboration data management
- Need both API and SQL access
- Want data stored in real PostgreSQL
Notes:
- Teable user needs superuser privileges
- Must configure
PUBLIC_ORIGINto external access address - Supports email notifications (optional SMTP configuration)
- Change
REDIS_PASSWORDwhen using the development cache template. The stable version requires external Redis and a completeBACKEND_CACHE_REDIS_URI. - Back up both PostgreSQL and application assets under
/data/teable.
32 - app/mattermost
The app/mattermost template deploys Mattermost with Pigsty-managed PostgreSQL, Nginx, and monitoring.
By default, the application and database share one node.
For application usage details, see Mattermost: Open-Source IM.
The preview below retains fixes such as the Bleve path. New Calls port mappings and directory preparation scripts require matching application updates; see the Mattermost application guide.
Overview
- Config Name:
app/mattermost - Node Count: Single node (default)
- Description: Deployment template for Mattermost, PostgreSQL, and Docker
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - Application Image Architecture:
x86_64(the official Team Edition image provides onlylinux/amd64; ARM64 emulation is for testing only) - Related:
app/odoo,app/registry,supabase
Usage:
Content
Source: pigsty/conf/app/mattermost.yml
Development configuration preview: Calls requires matching Compose port mappings
Explanation
The app/mattermost template defines three key groups:
mattermost: app host andapps.mattermostsettings, including.envoverrides and data directory definitionpg-mattermost: dedicated PostgreSQL cluster, database, and application accountinfra/etcd: shared Pigsty infrastructure dependencies
Key Features:
- Enables Docker runtime by default (
docker_enabled: true) and prepares it through./docker.yml - Exposes
mm.pigstyin the Nginx portal (infra_portal.mattermost) with WebSocket support - Includes a local Docker subnet HBA rule (
172.16.0.0/12) allowing only the application account to access themattermostdatabase apps.mattermost.filecreates data directories owned by2000:2000; the development template also adds Calls mappings for8443/TCPand8443/UDP- Provides optional JuiceFS settings (commented) to mount
/data/mattermoston PostgreSQL-backed storage
Notes:
- Change database credentials, domain names, and application secrets before deployment
- If the service is accessible from public networks, enable HTTPS and enforce ACL and firewall policies.
- Calls media traffic requires TCP and UDP.
node_firewall_public_portopens only TCP; see the application guide for details.
33 - app/registry
The app/registry template provides a reference configuration for Docker Registry as an image proxy. It acts as a Docker Hub pull-through cache by default.
Overview
- Config Name:
app/registry - Node Count: Single node
- Description: Deploy Docker Registry image proxy cache
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Source: pigsty/conf/app/registry.yml
Explanation
The app/registry template provides one-click deployment of a Docker Registry image proxy.
What is Registry:
- Docker’s official image registry implementation
- Can serve as Docker Hub pull-through cache
- This template’s proxy-cache mode does not accept image pushes
- Supports image caching and local storage
Key Features:
- Pins
registry:3.1.2andjoxit/docker-registry-ui:2.6.0by default - Acts as proxy cache for Docker Hub to accelerate image pulls
- Caches images to local storage
/data/registry - Provides Web UI to view cached images
- Supports custom cache expiration time
Configure Docker Client:
Edit /etc/docker/daemon.json:
Restart Docker:
Access:
Use Cases:
- Accelerate Docker image pulls (especially in mainland China)
- Reduce external network dependency
- Share a Docker Hub pull cache across hosts
Notes:
- Requires sufficient disk space to store cached images
- Default cache TTL is 7 days (
REGISTRY_PROXY_TTL: 168h) - Can configure HTTPS certificates (via certbot)
registry-mirrorsdoes not redirect GHCR / Quay; useREGISTRY_HTTP_PROXY/REGISTRY_HTTPS_PROXYfor container egress- Registry startup still depends on upstream availability; a populated cache is not an independent offline registry
- Preserve configuration and cache before upgrading, then verify manifest/blob digests and cold/hot pulls; see application details
34 - app/insforge
The app/insforge template deploys InsForge OSS.
It uses Pigsty-managed PostgreSQL as the external database.
For details, see: InsForge Deployment Tutorial
Overview
- Config Name:
app/insforge - Node Count: Single node
- Description: Deploy InsForge App, PostgREST, and Deno Runtime, and create the required PostgreSQL users, roles, databases, and extensions
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta,supabase
Usage:
Content
Source: pigsty/conf/app/insforge.yml
Explanation
The app/insforge template deploys by default:
- InsForge main service:
ghcr.io/insforge/insforge-oss:v2.3.3, port7130 - PostgREST:
postgrest/postgrest:v12.2.12, loopback endpoint127.0.0.1:5430 - Deno Runtime:
denoland/deno:alpine-2.0.6, loopback endpoint127.0.0.1:7133 - PostgreSQL database:
insforge - Extensions:
pgcrypto,http,pg_cron; also install and preloadinsforge_pg_utilson every database node - PostgreSQL 18 with
BYPASSRLSenabled forproject_admin - Local Docker-network HBA range:
172.16.0.0/12 - Nginx entrypoint:
isf.pigsty->10.10.10.10:7130
For a fresh deployment, initialize INFRA, install PostgreSQL packages and the pgutils library, then initialize the database. See the deployment steps. When upgrading an existing database to v2.3.3, let the application run migration 065 automatically; do not replay files/insforge.sql.
Access:
The default administration account is admin@example.com with password pigsty.
For production, replace JWT_SECRET, ENCRYPTION_KEY, ROOT_ADMIN_PASSWORD, and the database password.
Keep encryption and permission settings consistent with pg_parameters.
35 - app/hindsight
The app/hindsight template deploys Hindsight.
It replaces the built-in development database with external PostgreSQL managed by Pigsty.
For details, see: Hindsight Deployment Tutorial
Overview
- Config Name:
app/hindsight - Node Count: Single node
- Description: Deploy the Hindsight all-in-one container, create an external PostgreSQL database, and configure UI/API entrypoints
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Content
Source: pigsty/conf/app/hindsight.yml
Explanation
The app/hindsight template deploys by default:
- Hindsight container:
ghcr.io/vectorize-io/hindsight:latest - UI port:
9999 - API port:
8888 - PostgreSQL database:
hindsight - Default vector extension:
vector; also createspg_trgminpublic - Persists models in the
hindsight-cachenamed volume, withHF_HUB_OFFLINE=1by default - Nginx entrypoints:
hs.pigsty->9999,hs-api.pigsty->8888
Access:
With the default HINDSIGHT_API_LLM_PROVIDER=none, Hindsight can retain text and recall it using local models. Fact extraction and reflection require a real LLM backend. To use an uncached Hugging Face model, set HF_HUB_OFFLINE=0 and provide outbound network access.
36 - app/immich
The app/immich template deploys Immich.
It uses Pigsty-managed PostgreSQL 18 for metadata and vector indexes.
The template follows v3. On 2026-10-08, validation of Immich 3.3.0 on Linux amd64 with PostgreSQL 18.6 used a new media library and covered uploads, thumbnails, and machine-learning inference.
Overview
- Config Name:
app/immich - Node Count: Single node
- Application Port:
2283 - Data Directory:
/data/immich/library - Related:
meta,app/registry
Usage:
Content
Source: pigsty/conf/app/immich.yml
Explanation
- Persists application media under
/data/immich/library - Creates the
pg-immichPostgreSQL cluster and matching database/service account - Installs
pgvectorandvchord, then createsvchordandearthdistance, pluspg_trgminpublic - Preloads
vchord.soand setsDB_VECTOR_EXTENSION: vectorchord - Uses a local Valkey 9 service pinned by digest to match Immich 3.3.0’s official Compose, rather than a Pigsty Redis cluster
- Proxies
photo.pigstyto10.10.10.10:2283
Before deployment, change the database password, domain, and media path.
Make sure that the target platform supplies a vchord package for PostgreSQL 18.
37 - app/jumpserver
The app/jumpserver template deploys JumpServer Community Edition.
It uses Pigsty-managed PostgreSQL 18 as its external database.
The current validation uses JumpServer v5.0.0-ce.
Overview
- Config Name:
app/jumpserver - Node Count: Single node
- Web Port:
8080 - SSH Port:
2222 - KoKo Website Proxy Port:
5001 - Image Namespace:
registry.cn-beijing.aliyuncs.com/jumpservice - Tested Platform: Linux amd64; external PostgreSQL 18.6
- Related:
meta
Usage:
Content
Source: pigsty/conf/app/jumpserver.yml
Explanation
- Creates persistent directories under
/data/jumpserverfor Core, KoKo, Kael, Chen, Nginx, and Redis - Uses the fixed Docker subnet
192.168.250.0/24with matching PostgreSQL and PgBouncer HBA rules - Creates the
pg-jumpservercluster and matchingjumpserverdatabase/service account - Runs Redis inside the application Compose stack
- Proxies
jump.pigstyto10.10.10.10:8080
Before deployment, replace SECRET_KEY, BOOTSTRAP_TOKEN, CHAT_AI_DELEGATION_SECRET, Redis and database passwords, and the domain.
After production data exists, keep SECRET_KEY unchanged.
The one-shot init service migrates the database and validates the host key before Core starts. Celery and connection components wait for Core health. jms_init should be Exited (0). See the JumpServer application guide for installation, the 4.10.19 upgrade, backup, recovery, and acceptance checks.
38 - demo/bare
demo/bare is the smallest Pigsty configuration example.
It defines three core groups and three global parameters to show the basic inventory structure.
Overview
Content
Source: pigsty/conf/demo/bare.yml
Explanation
This template uses Pigsty defaults. It defines no business users, databases, extensions, backup policy, or security hardening. Use it to learn the configuration hierarchy or as a starting point for your own configuration. Before use in a real environment, add passwords, HBA rules, backups, and the required safeguards.
39 - demo/el
The demo/el template supplies configuration for Enterprise Linux distributions.
These include RHEL, Rocky Linux, Alma Linux, and Oracle Linux.
Overview
- Config Name:
demo/el - Node Count: Single node
- Description: Enterprise Linux optimized configuration template
- OS Distro:
el8,el9,el10 - OS Arch:
x86_64,aarch64 - Related:
meta,demo/debian
Usage:
Content
Source: pigsty/conf/demo/el.yml
Explanation
Use demo/el for the following Enterprise Linux distributions.
Supported Distributions:
- RHEL 8/9/10
- Rocky Linux 8/9/10
- Alma Linux 8/9/10
- Oracle Linux 8/9
Key Features:
- Uses EPEL and PGDG repositories
- Uses settings for the YUM/DNF package manager
- Supports EL-specific package names
Use Cases:
- Enterprise production environments (RHEL/Rocky/Alma recommended)
- Long-term support and stability requirements
- Environments using Red Hat ecosystem
40 - demo/debian
The demo/debian template supplies configuration for Debian and Ubuntu.
Overview
- Config Name:
demo/debian - Node Count: Single node
- Description: Debian/Ubuntu optimized configuration template
- OS Distro:
d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta,demo/el
Usage:
Content
Source: pigsty/conf/demo/debian.yml
Explanation
Use demo/debian for the following Debian and Ubuntu versions.
Supported Distributions:
- Debian 12 (Bookworm)
- Debian 13 (Trixie)
- Ubuntu 22.04 LTS (Jammy)
- Ubuntu 24.04 LTS (Noble)
- Ubuntu 26.04 LTS (Resolute)
Key Features:
- Uses PGDG APT repositories
- Uses settings for the APT package manager
- Supports Debian/Ubuntu-specific package names
Use Cases:
- Cloud servers (Ubuntu widely used)
- Container environments (Debian commonly used as base image)
- Development and testing environments
41 - demo/demo
Pigsty’s public demonstration site uses the demo/demo template.
It shows public service access, SSL certificate configuration, and installation of all available extensions.
Use this template as a reference for a public service on a cloud server.
Overview
- Config Name:
demo/demo - Node Count: Single node
- Description: Pigsty public demo site configuration
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64 - Related:
meta,rich
Usage:
Key Features
This template enhances the meta template with:
- SSL certificate and custom domain configuration (e.g.,
pigsty.cc) - Downloads and installs all available PostgreSQL 18 extensions
- Enables Docker with image acceleration
- Deploys Silo object storage
- Pre-configures multiple business databases and users
- Adds Redis primary-replica instance examples
- Adds Kafka sample cluster
Content
Source: pigsty/conf/demo/demo.yml
Explanation
The demo/demo template is Pigsty’s public demonstration configuration.
It shows how to configure the components of a complete deployment.
Key Features:
- HTTPS certificate and custom domain configuration
- All available PostgreSQL extensions installed
- Integration with Redis, Kafka, and other components
- Docker image acceleration configured
Use Cases:
- Setting up public demo sites
- Scenarios requiring complete feature demonstration
- Learning Pigsty advanced configuration
Notes:
- Prepare the SSL certificate files.
- Configure DNS resolution.
- Some extensions are not available on ARM64 architecture
42 - demo/kernel
The demo/kernel template demonstrates the PostgreSQL kernels and compatible branches that Pigsty supports.
Use it to validate features and compare kernel behavior.
Do not use this demonstration template for production.
Overview
- Config Name:
demo/kernel - Node Count: 10 nodes, with one node also hosting INFRA/ETCD and
pg-citus - Description: PostgreSQL kernel matrix demo covering Citus, IvorySQL, Babelfish, PolarDB, Percona TDE, OrioleDB, OpenHalo, DocumentDB, AgensGraph, and pgEdge
- OS Distro: depends on actual package support for each kernel
- OS Arch: depends on actual package support for each kernel
- Related:
pgsql,mssql,mongo
Usage:
Note: This is a fixed-IP demo template. Adjust node addresses for your actual environment after generation.
Content
Source: pigsty/conf/demo/kernel.yml
Explanation
This template uses single-node clusters to show the minimum viable configuration for different kernels:
pg-citus: PostgreSQL 18 + Cituspg-ivory: IvorySQL, compatible with PostgreSQL 18pg-mssql: Babelfish, compatible with PostgreSQL 17pg-polar: PolarDB for PostgreSQL, compatible with PostgreSQL 17pg-tde: Percona PostgreSQL 18 +pg_tdepg-oriole: OrioleDB with PostgreSQL 16, 17, and 18 support. The current demonstration defaults to PG18.pg-mysql: OpenHalo, compatible with PostgreSQL 14pg-mongo: DocumentDB backend for PostgreSQL Mongo mode, default PostgreSQL 18pg-agens: AgensGraph, compatible with PostgreSQL 17pg-edge: pgEdge, compatible with PostgreSQL 18
Notes:
- Package support varies by kernel, OS, and architecture. Confirm the target repository is available before deployment.
- This template has permissive access rules for demonstrations. For production, use a dedicated kernel template and restrict HBA and password policies.
43 - demo/minio
demo/minio demonstrates a highly available S3 object-storage cluster. The cluster has four nodes and four drives per node, for a total of 16 drives.
The template retains MINIO module names for compatibility and explicitly sets minio_type: silo. The current v4.5.0 source accepts only this value. The deployment and removal roles both default to silo. Before removal, verify this value, the exact target, the cluster identity, and the data paths.
For more tutorials, see the MINIO module documentation.
Overview
- Config Name:
demo/minio - Node Count: Four nodes
- Description: High-availability multi-node multi-drive S3 object-storage demo (currently defaults to Silo)
- OS Distro:
el8,el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64,aarch64 - Related:
meta
Usage:
Note: This template has four nodes. After you generate the configuration, change the IP addresses of the other three nodes.
Content
Source: pigsty/conf/demo/minio.yml
Explanation
demo/minio provides a reference configuration for production object storage. It uses the Multi-Node Multi-Drive (MNMD) architecture. Its volume layout, HAProxy health checks, and clients retain MinIO-compatible interfaces.
Key Features:
- Multi-Node Multi-Drive Architecture: 4 nodes × 4 drives = 16-drive erasure coding group
- L2 VIP High Availability: Virtual IP binding via Keepalived
- HAProxy Load Balancing: Unified access endpoint on port 9002
- Fine-grained Permissions: Separate users and buckets for different applications
Access:
Use Cases:
- Environments requiring S3-compatible object storage
- PostgreSQL backup storage (pgBackRest remote repository)
- Data lake for big data and AI workloads
- Production environments requiring high-availability object storage
Notes:
- Each node requires 4 independent disks mounted at
/data1-/data4 - The VM example uses
vm_image: u24and declares asize: 64data disk for each mount throughvm_disks. For existing hosts, verify the actual mounts and capacity. - We recommend at least 4 nodes for erasure coding redundancy in production.
- VIP requires proper network interface configuration (
vip_interface)
44 - demo/redis
The demo/redis configuration demonstrates the standalone/replica, Sentinel, and native Cluster modes of Pigsty’s Redis module.
Overview
- Config Name:
demo/redis - Node Count: 4
- Clusters:
redis-ms,redis-meta,redis-test - Related:
demo/demo
Content
Source: pigsty/conf/demo/redis.yml
Explanation
redis-ms: a6379primary and6380replica on one noderedis-meta: three Sentinel instances monitoring theredis-msprimaryredis-test: a native Redis Cluster across two nodes with three instances per node- Small per-instance memory limits keep the topology suitable for demonstrations
The IP addresses, passwords, and memory limits are demonstration values. Adjust these values for the real topology. Then install the Redis module with the redis.yml playbook.
45 - demo/kafka
The demo/kafka template defines two Kafka 4.x dynamic KRaft clusters on four nodes.
The development cluster kf-meta uses one node and plaintext connections.
The demonstration cluster kf-test uses three nodes with TLS, SCRAM, and ACLs.
Overview
- Config Name:
demo/kafka - Node Count: 4
kf-meta: Single combined Broker/Controller node in plaintext modekf-test: Three combined nodes with TLS/SCRAM/ACL, topic replication factor 3, andmin.insync.replicas=2- Module Status: KAFKA BETA
The deploy.yml playbook deploys only the core modules.
It does not run the KAFKA playbook.
For each kafka.yml run, select one complete Kafka cluster.
The role rejects operations that select only part of a cluster.
Content
Source: pigsty/conf/demo/kafka.yml
Explanation
kf-metacreatesquickstart.eventsfor single-node development and connectivity tests.kf-testcreates thetest-appSCRAM user, prefix ACLs, and the three-replicatest.eventstopic.kf-testexplicitly setskafka_heap_opts: '-Xms512M -Xmx512M'for 2 GiB demo nodes. Size production nodes for the actual workload.- Online installation maps the platform packages
kafka-stackandjava-runtime. For installation with only a local repository, cache both complete package groups first. - Addresses and passwords in the template are demonstration values. Replace them for your topology and security requirements before deployment.
See the KAFKA module for operations, security, and scaling constraints.
46 - demo/mysql
demo/mysql provides a four-node example for the native MySQL 8.4 LTS pilot module. The separate conf/mysql.yml template provides MySQL protocol compatibility through the OpenHalo PostgreSQL kernel.
Overview
- Config Name:
demo/mysql - Node Count: 4
my-meta: Standalone MySQL 8.4 instancemy-test: Three-node, single-primary InnoDB Cluster with MySQL Router on every member- Module Status: MYSQL PILOT; not included in the stable module count
- Platform Boundary: Declared supported x86_64 RPM/DEB platforms and EL9/EL10 aarch64. Oracle APT currently has no arm64 component. Thus, preflight rejects Debian/Ubuntu ARM.
Replace every CHANGE_ME value in the template. Real deployment also requires explicit approval. Start with read-only preflight checks:
First, explicitly approve the active-inventory update. Then run ./configure -c demo/mysql. Run both node.yml and mysql.yml with --check. Then run both playbooks to apply the configuration. Use the same complete cluster scope for these operations. The three-node cluster does not accept a partial-member scope.
Content
Source: pigsty/conf/demo/mysql.yml
Explanation
- MySQL server, client, Shell, Router, and XtraBackup are fixed to the 8.4 platform. The installer does not support arbitrary versions.
- The standalone instance uses
3306. The three-node cluster also uses Group Replication on33061. Each member has Router RW on6446and RO on6447. - A daily local full XtraBackup and
mysqld_exporterare enabled by default. The current pilot does not provide continuous binlog archiving, PITR, or automatic recovery. node.ymlinstalls the shared trust anchor at/etc/pki/ca.crt. The MySQL role only issues and installs leaf certificates.
See the native MySQL pilot documentation for complete constraints and the confirmed removal workflow.
47 - build/oss
The build/oss template configures a build environment for offline packages of the Pigsty open-source edition. Use it to build offline installation packages for multiple operating systems in batches.
This configuration is intended for developers and contributors only.
Overview
- Config Name:
build/oss - Node Count: Seven nodes (el9, el10, d12, d13, u22, u24, u26)
- Description: Pigsty open-source edition offline package build environment
- OS Distro:
el9,el10,d12,d13,u22,u24,u26 - OS Arch:
x86_64
Usage:
Note: This build template uses fixed IP addresses. It is for internal use only.
Content
Source: pigsty/conf/build/oss.yml
Explanation
The build/oss template is the build configuration for Pigsty open-source edition offline packages.
Build Contents:
- PostgreSQL 18 and all categorized extension packages
- Infrastructure packages (VictoriaMetrics, Grafana, Nginx, etc.)
- Node packages (monitoring agents, tools, etc.)
- Extra modules
The template also sets VM defaults vm_cpu: 2 and vm_mem: 4096, plus a matching vm_image and nodename on each node, to create build environments for each operating system.
Supported Operating Systems:
- EL9 (Rocky/Alma/RHEL 9)
- EL10 (Rocky 10 / RHEL 10)
- Debian 12 (Bookworm)
- Debian 13 (Trixie)
- Ubuntu 22.04 (Jammy)
- Ubuntu 24.04 (Noble)
- Ubuntu 26.04 (Resolute)
Build Process:
Use Cases:
- Pigsty developers building new versions
- Contributors testing new extensions
- Enterprise users customizing offline packages
48 - build/dev
The build/dev template defines a local environment with three nodes for Pigsty development.
It tests repository builds and package downloads on EL9, Debian 12, and Ubuntu 24.
Use this template only for development and contribution work.
Overview
- Config Name:
build/dev - Node Count: Three nodes (
el9,d12,u24) - Description: Local build and development environment, default PostgreSQL 18, builds the
infra,node,pgsqlmodules - OS Distro:
el9,d12,u24 - OS Arch:
x86_64,aarch64 - Related:
build/oss
Usage:
Note: This is a fixed-IP development build template. Adjust host addresses for your local environment before use.
Content
Source: pigsty/conf/build/dev.yml
Explanation
Use build/dev to validate the Pigsty software repository build process.
It is not intended for ordinary production installation.
Key Features:
- Default
pg_version: 18 - Local cache directory is
dist/${version} - Builds
infra,node,pgsqlmodules by default - Preloads PostgreSQL 18 full-category extension package groups
- Covers both RPM and DEB build paths through three distro nodes
Use Cases:
- Pigsty new version build validation
- Software repository and mirror source debugging
- Extension package download and cache testing
49 - demo/remote
demo/remote declares multiple pg_exporters on an INFRA node. These exporters monitor remote PostgreSQL, PolarDB, or cloud RDS instances. The template does not deploy a local PostgreSQL cluster.
Overview
- Config Name:
demo/remote - Local Node Count: One INFRA node
- Example Exporter Ports:
20001-20016 - Related: PG Exporter
Content
Source: pigsty/conf/demo/remote.yml
Explanation
Each pg_exporters entry uses a unique local listen port. It declares the remote instance’s pg_cluster, pg_seq, pg_host, and optional connection settings. The template demonstrates complete URLs, split credentials, database allowlists, and auto-discovery.
All hostnames and credentials are placeholders. Keep only the entries you need. Use a monitoring account with the minimum required privileges. Never commit real RDS passwords.
50 - demo/saas
demo/saas is a legacy single-node example with many features. It includes predefined business users, databases, and application entrypoints. It demonstrates how to combine PostgreSQL, Silo, Redis, Docker, and the portal.
Overview
- Config Name:
demo/saas - Node Count: Single node
- Modules: INFRA, ETCD, MINIO, PGSQL, REDIS, DOCKER
- Related:
rich,supabase
Content
Source: pigsty/conf/demo/saas.yml
Explanation
The template contains placeholder database users and databases for Grafana, Bytebase, Kong, Gitea, Wiki, NocoDB, and Odoo. It uses Silo as the pgBackRest repository. It also includes a Redis replica example and multiple portal domains.
This compatibility/reference bundle does not install every listed application automatically. For new deployments, prefer rich plus the relevant app/* template. First, remove unused users, databases, and entrypoints. Replace all passwords.
51 - demo/wool
demo/wool targets small cloud instances in China. It defaults to region: china, PostgreSQL 18, and the tiny tuning profiles.
Overview
- Config Name:
demo/wool - Node Count: Single node
- Suggested Size: Approximately 2 vCPU / 2 GB for testing
- Related:
meta,slim
Content
Source: pigsty/conf/demo/wool.yml
Explanation
- Explicitly sets
pg_conf: tiny.ymlandnode_tune: tinyonpg-meta - Expects
10.10.10.10to be replaced by the cloud instance’s private IP - Disables pgBackRest by default to reduce disk usage on a small test host
- Includes several example portal domains
This template reduces resource use by disabling backups. It is suitable only for temporary testing.
For production deployments, you must enable and verify backups. Tighten the network rules, replace default passwords, and remove unused portal entries.