Addons

pgcli addon management guide

pgcli supports extending PostgreSQL capabilities through an addon system. Addons are standalone containers that provide additional functionality for PostgreSQL instances without modifying the database itself.

Supported Addons

The following addons are currently supported:

Addon	Description
`pgbouncer`	Connection pool manager with transaction-level pooling
`etcd`	Distributed key-value store — standalone, clusterable, for HA / DCS use
`pgdog`	Postgres proxy — connection pooling, load balancing and sharding
`postgrest`	Expose a PostgreSQL schema as a REST API — single stateless container, local or remote (any PG endpoint)
`haproxy`	TCP load balancer in front of a Patroni cluster — unified or read/write split (Linux only)
`minio`	S3-compatible object storage with web console — standalone or distributed erasure-coded cluster across hosts (Linux and macOS)
`silo`	S3-compatible object storage (Pigsty’s MinIO fork) — same feature surface as the minio addon, shares one port pool; ships its own `mcli` client (Linux and macOS)
`rustfs`	S3-compatible object storage (Rust reimplementation) — SNSD/SNMD/MNMD erasure-coded layouts, fixed container uid handled inside pgcli’s wrapper image, shares the one port pool (Linux only)

Each addon has its own page with commands, parameters, and troubleshooting.

Patroni HA (pg ha) is not on this list — it is not installed via pg addon but is its own top-level command, and its documentation now lives in a dedicated HA Cluster section. etcd and HAProxy here are addons a pg ha cluster can use.

How It Works

Addons run as standalone containers managed through pg.yaml:

pg addon install generates configuration and starts the addon container
Config and data live under <base-dir>/addon/<addon-name>/
Addon containers communicate over the host network
Containers automatically restart when configuration is updated

Namespace isolation: Addons respect the config’s namespace setting — container names include the namespace prefix, so different config files can manage independent addons without conflicting.

Common Commands

pg addon install <addon> [flags]   # install / reconfigure (idempotent)
pg addon list                       # show all installed addons and status
pg addon remove <addon> [flags]     # remove the addon, container, and data

See each addon’s page for its specific flags and examples: Pgbouncer · etcd · PgDog · PostgREST · HAProxy · MinIO · Silo · rustfs. Patroni pages live in HA Cluster.

PgBouncer

Connection pooling for PostgreSQL instances via the PgBouncer addon

Etcd

Run a standalone etcd cluster as a pgcli addon for HA / DCS use

PgDog

Run PgDog — a Postgres proxy for connection pooling, load balancing and sharding — as a pgcli addon

PostgREST

Expose a PostgreSQL schema as a REST API via the PostgREST addon

RustFS

Run rustfs (the Rust S3-compatible object store) as a pgcli addon — single-node or erasure-coded, with the fixed container uid handled inside a purpose-built image

HAProxy

Run HAProxy as a pgcli addon — a TCP load balancer in front of a Patroni cluster, in unified (read-write) or split (read/write separation) mode

Silo

Run silo (Pigsty’s MinIO fork) as a pgcli addon — single-node or distributed S3-compatible object storage with web console

MinIO

Run MinIO as a pgcli addon — single-node or distributed S3-compatible object storage with web console