| title | Kubernetes how-to guides |
|---|---|
| description | Recipe-style pages for running pg_hardstorage on Kubernetes — Helm charts and operator integrations. |
Pages for running pg_hardstorage on Kubernetes. Three shapes:
- Helm charts ship today for the host agent and reserve the chart name for the control plane.
- Drop-in shims (pgBackRest / Barman / WAL-G) ship in v1.1; they let an existing operator stack keep its pod / image / config shape and swap the backup binary underneath.
- CNPG-I provider for CloudNativePG is the long-form native integration on the v0.5 roadmap.
- Deploy the sidecar Helm chart — the StatefulSet that runs the host agent for an external Postgres cluster.
- Deploy the server Helm chart — status and roadmap for the control-plane chart.
- Run as a pgBackRest shim (Crunchy PGO)
— drop-in replacement for
pgbackrestinside Crunchy'sPostgresCluster. - Run as a Barman shim (host-managed PG)
— drop-in replacement for
barman/barman-wal-archivein pod-side wrappers. - Run as a WAL-G shim (Zalando) — drop-in
replacement for
wal-gagainst the Zalando postgres-operator.
- Use the CloudNativePG-I provider —
CNPG
Clusterplus our backup primitive underneath.
| You run | Use |
|---|---|
| External self-managed PG (VM / bare metal / non-operator) | Sidecar chart |
| CloudNativePG (CNPG) | CNPG-I provider (v0.5) |
| Zalando postgres-operator | WAL-G shim |
| Crunchy PGO | pgBackRest shim |
| Custom Barman pod (cron / Job) | Barman shim |
The sidecar chart pointed at the cluster's external endpoint is always a viable alternative — it coexists with whatever the operator is doing and gives you pg_hardstorage backups in your own repo without touching the existing stack.