Back to results
Operand images for all community-supported PostgreSQL versions.
- stars
- 158
- watchers
- 6
- forks
- 67
- open issues
- 3
- Last updated
- 10/29/2026
gem-hunterOperand images for all community-supported PostgreSQL versions.
IMPORTANT: Starting in August 2025, the Official Postgres Image, maintained by the PostgreSQL Docker Community, has discontinued support for Debian
bullseye. In response, the CloudNativePG project has completed the transition to the newbake-based build process for allsystemimages. We now build directly on top of the official Debian slim images, fully detaching from the official Postgres image.
This repository provides maintenance scripts for generating immutable application containers for all supported PostgreSQL major versions:
| Version | Release Date | EOL |
|---|---|---|
| 18 | 2025-09-25 | 2030-11-14 |
| 17 | 2024-09-26 | 2029-11-08 |
| 16 | 2023-09-14 | 2028-11-09 |
| 15 | 2022-10-13 | 2027-11-11 |
| 14 | 2021-09-30 | 2026-11-12 |
| 13 | 2020-09-24 | 2025-11-13 |
In addition, PostgreSQL 19 RC 1 is provided for testing purposes only.
These images are designed to serve as operands of the CloudNativePG (CNPG) operator in Kubernetes environments, and are not intended for standalone use.
CloudNativePG PostgreSQL container images:
stable and oldstable).linux/amd64 and
linux/arm64.CloudNativePG PostgreSQL container images are based on the official stable
and oldstable Debian releases, maintained and supported by the
Debian Project.
The table below summarises the support lifecycle of relevant Debian versions, including End-of-Life (EOL) and Long-Term Support (LTS) dates.
| Name | Version | Release Date | EOL | LTS | Status |
|---|---|---|---|---|---|
Trixie (stable) |
13 | 2025-08-09 | 2028-08-09 | 2030-06-30 | Supported |
Bookworm (oldstable) |
12 | 2023-06-10 | 2026-06-10 | 2028-06-30 | Supported |
IMPORTANT: The CloudNativePG project provides full support for Debian-based images until each release reaches its official End-of-Life (EOL). After EOL and until the start of Long-Term Support (LTS), images for the deprecated releases, such as
oldoldstable, are maintained on a best-effort basis. If discontinuation becomes necessary before the LTS date, a minimum three-month advance notice will be posted on this page.
We currently provide and maintain three main types of PostgreSQL images:
Both minimal and standard images are designed to work with backup plugins
such as Barman Cloud.
The system images, built on top of the standard ones, also include the
Barman Cloud binaries.
Minimal images are lightweight and built on top of the official Debian images. They use the APT PostgreSQL packages maintained by the PostgreSQL Global Development Group (PGDG).
These images are identified by the inclusion of minimal in their tag names,
for example: 17.6-minimal-trixie.
Note
Starting with PostgreSQL 18, minimal images will not include
LLVM JIT support (shipped in the postgresql-MM-jit package, where MM
represents the PostgreSQL major version). JIT will be available only in the
standard image.
Standard images are an extension of the minimal images, enhanced with the
following additional features:
minimal imagespostgresql-MM-jit
packageStandard images are identifiable by the standard tag in their names, such as:
17.6-standard-trixie.
Note
Standard images are designed to offer functionality equivalent to
the legacy system images when used with CloudNativePG. To achieve parity,
you must use the Barman Cloud Plugin
as a replacement for the native Barman Cloud support in system images.
Starting from September 2025, system images are based on the standard image
and include Barman Cloud binaries.
Important
The system images are deprecated and will be removed once
in-core support for Barman Cloud in CloudNativePG is phased out. While you
can still use them as long as in-core Barman Cloud remains available, you
should plan to migrate to either a minimal or standard image together
with the Barman Cloud plugin—or adopt another supported backup solution.
Each image is identified by its digest and a main tag of the form:
MM.mm-TS-TYPE-OS
where:
MM is the PostgreSQL major version (e.g. 16)mm is the PostgreSQL minor version (e.g. 10)TS is the build timestamp with minute precision (e.g. 202509090953)TYPE is image type (e.g. minimal)OS is the underlying distribution (e.g. trixie)For example: 16.10-202509090953-minimal-trixie.
In addition to fully qualified tags, rolling tags are available in the following formats:
MM.mm-TYPE-OS: latest image for a given PostgreSQL minor version
(16.10) of a specific type (minimal) on a Debian version (trixie).
For example: 16.10-minimal-trixie.MM-TYPE-OS: latest image for a given PostgreSQL major version (16) of
a specific type (minimal) on a Debian version (trixie).
For example: 16-minimal-trixie.While the most reliable way to reference an image is by its digest, the
MM.mm-TYPE-OS tag usually provides a good balance between stability and
convenience for most use cases.
For historical reasons, the system image used to carry two additional rolling
tags:
MM.mm: latest system image for a given PostgreSQL minor version (e.g.
16.10) on Debian bullseye.MM: latest system image for a given PostgreSQL major version (e.g.
16) on Debian bullseye.IMPORTANT: These tags are deprecated, they aren't being generated anymore
and existing ones will be removed from the container registry.
Please migrate to one of the supported tag formats that explicitly include
both the image type and the distribution version (e.g. 16.10-minimal-trixie).
CloudNativePG publishes ClusterImageCatalog manifests for CloudNativePG in
the artifacts repository,
with one catalog available for each supported combination of image type and
operating system version.
IMPORTANT: If you are still relying on the legacy
ClusterImageCatalog-bookworm.yaml
manifest, please migrate to the new catalog as soon as possible. This legacy
manifest is deprecated and will be removed along with the system image.
CNPG PostgreSQL Container Images are built with the following attestations to ensure transparency and traceability:
Software Bill of Materials (SBOM): A comprehensive list of software artifacts included in the image or used during its build process, formatted using the in-toto SPDX predicate standard.
Provenance: Metadata detailing how the image was built, following the SLSA Provenance framework.
For example, to retrieve the SBOM of a multi-architecture image for a specific
platform (e.g. linux/amd64), you can use the following command:
docker buildx imagetools inspect <IMAGE> \ --format '{{ json (index .SBOM "linux/amd64").SPDX }}'
This command outputs the SBOM in JSON format, providing a detailed view of the software components and build dependencies.
The minimal and standard CloudNativePG container images are securely signed using
cosign, a tool within the
Sigstore ecosystem.
This signing process is automated via GitHub Actions and leverages
short-lived tokens issued through OpenID Connect.
The token issuer is https://token.actions.githubusercontent.com, and the
signing identity corresponds to a GitHub workflow executed under the
cloudnative-pg/postgres-containers repository. This workflow uses the
cosign-installer action
to facilitate the signing process.
To verify the authenticity of an image using its digest, you can run the
following cosign command:
cosign verify IMAGE \ --certificate-identity-regexp="^https://github.com/cloudnative-pg/postgres-containers/" \ --certificate-oidc-issuer="https://token.actions.githubusercontent.com"
To further strengthen the security of our container images, we perform automated image scanning as part of our CI/CD workflows. These scans help ensure that our images adhere to best practices and remain free of known vulnerabilities before they are published or deployed:
For detailed instructions on building PostgreSQL container images, refer to the BUILD.md file.
Renovate can be used to automatically update various dependencies.
As CloudNativePG's Cluster CRDs are not automatically picked up by Renovate, a custom regex manager must be configured.
The example below uses JSON5; save it as renovate.json5, or convert keys/comments for use in renovate.json:
{ customManagers: [ { // CloudNativePG Cluster imageName customType: 'regex', managerFilePatterns: [ '/\\.yaml$/', ], matchStrings: [ 'imageName: (?<depName>[^\\s:]+):(?<currentValue>[^\\s@]+)(?:@(?<currentDigest>sha256:[a-f0-9]{64}))?', ], datasourceTemplate: 'docker', // matches: 17.6-202509151215-minimal-trixie versioningTemplate: 'regex:^(?<major>\\d+)\\.(?<minor>\\d+)-(?<patch>\\d+)-(?<compatibility>\\S+)$', autoReplaceStringTemplate: 'imageName: {{{depName}}}:{{{newValue}}}{{#if newDigest}}@{{{newDigest}}}{{/if}}', } ], packageRules: [ { matchPackageNames: ['ghcr.io/cloudnative-pg/postgresql'], matchUpdateTypes: ['major'], dependencyDashboardApproval: true, } ] }
Renovate will never change the compatibility part of the tag (image flavour and Debian base, e.g. system-bookworm), so upgrades stay on the same OS and glibc/ICU.
Switching to a different base (e.g. from bookworm to trixie) is a manual operation because of PostgreSQL locale-data implications.
PostgreSQL major-version updates are routed through the dependency dashboard so they can be planned and applied by a human.
To keep references fully reproducible, you can also enable pinDigests scoped to the CloudNativePG image.
If your repository contains other YAML manifests, narrow managerFilePatterns to the directory holding your Cluster resources, e.g. '/clusters/.*\\.yaml$/'.
This software is available under Apache License 2.0.
Copyright © contributors to CloudNativePG, established as CloudNativePG a Series of LF Projects, LLC.
Barman Cloud is distributed by EnterpriseDB under the GNU GPL 3 License.
PGAudit is distributed under the PostgreSQL License.
Postgres Failover Slots is distributed by EnterpriseDB under the PostgreSQL License.
pgvector is distributed under the PostgreSQL License.
Postgres, PostgreSQL and the Slonik Logo are trademarks or registered trademarks of the PostgreSQL Community Association of Canada, and used with their permission.