Migrating from Bitnami

If you relied on Bitnami container images or Helm charts, the CommonLayer migration catalog in projects/bitnami-migration/ is the place to start: researched facts about what changed in the Bitnami catalog (with sources and access dates), a candidate entry for twenty commonly used applications with an honest status, and deep migration guides for the applications CommonLayer builds. This page only points into it; the catalog itself is the maintained source.

Where to read

Document	Content
Catalog README	What happened in five lines, the catalog table (status, priority, upstream license), status legend, licensing rule, how to propose a candidate
RESEARCH.md	Sourced findings about the Bitnami catalog as of 2026-11-10, including what could not be verified
General migration guide	Image and chart references, UID 1001 versus 10001 and existing volumes, environment variables, paths, security defaults, upgrade and rollback
PostgreSQL guide	Including why the default path is a logical migration (glibc collations versus ICU on musl)
Redis / Valkey guide	CommonLayer ships Valkey
NGINX guide	Configuration layout and ports
`projects/bitnami-migration/candidates/<slug>/`	Per candidate: README, `MIGRATION.md`, `commonlayer.yaml` (`kind: MigrationCandidate`)

The platform loads the candidate manifests (catalog sync) and serves them at GET /api/v1/migration-candidates; the portal's /alternatives/bitnami pages render them.

State of the catalog

nginx, Redis/Valkey and PostgreSQL are in_development: the projects exist in this repository (projects/nginx, projects/valkey, projects/postgresql), their images and charts are built and tested, and the three deep guides describe the real images and the real chart values. Nothing has been published to a CommonLayer registry, signed or attested, so there is nothing to pull from CommonLayer yet; to try a migration, build the images yourself. The entries become available with the first release (ADR-0042).
How far each was tested: nginx and PostgreSQL 16, 17 and 18 passed build, tests, scan gate and SBOM on GitHub runners, and the nginx chart installed and upgraded on kind there; the PostgreSQL HA chart's failover test passed once on a runner and failed in its next, reorganised form. Valkey passed every test locally, but its Sentinel failover test fails on GitHub runners, so its scan, SBOM and chart steps have not run there. See the implementation status.
Scanner coverage: the main software of these images is built from source and declared in the SBOM; only Grype matches those declarations, Trivy does not (ADR-0039). Each project's docs/SECURITY.md says what the scanners see.
Most other candidates are plans (planned), research_needed, blocked (upstream license does not allow redistribution, for example MongoDB under SSPL) or not_suitable (for example MinIO, whose upstream was archived). The catalog says which and why. No candidate is available.
The catalog's licensing rule for candidates (OSI-approved upstream license required) is a proposal awaiting confirmation by whoever operates CommonLayer.

Key differences to plan for

User and volumes. CommonLayer images run as UID/GID 10001, not 1001; existing persistent volumes need their ownership changed (the general guide shows how).
Paths. Configuration in /etc/commonlayer/<app>, data in /var/lib/commonlayer/<app>.
Environment variables. Prefixed with the application name; where the upstream official image has an established variable (such as POSTGRES_PASSWORD), the same name works. Secrets can be files (<VAR>_FILE).
Digests. CommonLayer charts default to image digests; pin digests in your own manifests too. See using the registry and verifying artifacts.
PostgreSQL collations. CommonLayer PostgreSQL uses ICU on musl (ADR-0021); reusing a glibc data directory requires a reindex, so dump and restore is the default.