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 new bake-based build process for all system images. 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:

In addition, PostgreSQL 19 Beta 3 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:

• Are built on top of Debian Linux (stable and oldstable).
• Provide multi-architecture support, including linux/amd64 and linux/arm64.
• Ship with build attestations, such as Software Bills of Materials (SBOMs) and provenance metadata.
• Are published in the CloudNativePG GitHub Container Registry.
• Are automatically rebuilt every week (on Mondays) to remain up to date with the latest upstream security and bug fixes.

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.

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:

• minimal
• standard
• system

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.

Standard images are an extension of the minimal images, enhanced with the following additional features:

• PGAudit
• Postgres Failover Slots
• pgvector
• All Locales
• LLVM JIT support
  • For PostgreSQL 17 and earlier: included in the main PostgreSQL packages, also available in minimal images
  • From PostgreSQL 18 onwards: provided by the separate postgresql-MM-jit package

Standard images are identifiable by the standard tag in their names, such as: 17.6-standard-trixie.

Starting from September 2025, system images are based on the standard image and include Barman Cloud binaries.

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 also carries 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 and will be removed when bullseye images reach end of life. 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-bullseye.yaml and ClusterImageCatalog-bookworm.yaml manifests, please migrate to the new catalogs as soon as possible. These legacy manifests are 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:

• Dockle: Verifies configuration best practices for container images. Runs during the build stage; critical failures can block the build.
• Snyk: Detects vulnerabilities in OS packages, libraries, and dependencies within the container. Runs after image build.

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.