Bitnami alternatives: migrate charts, images and application data

A deployment that worked yesterday can fail when a new Kubernetes node tries to download an image that is no longer available. If your applications use Bitnami packages, you need to identify which charts and images they depend on before choosing replacements.

Bitnami distributes packaged applications. A Helm chart describes how Kubernetes should run an application; a container image contains the software it runs. They are separate downloads. Keeping a chart's source code on GitHub does not guarantee that its referenced images remain available or receive security updates.

Bitnami changed its public catalog in 2025, and its legacy image catalog is an unmaintained migration aid. A temporary mirror may help an application start, but a lasting replacement also needs maintained software and a tested way to move its data. This guide helps you find that replacement and rehearse the change for each application.

Identify which distribution change affected you

The 2025 catalog changes and the 2026 AWS retirement are separate events. In a 21 May maintainer notice, Bitnami announced removal of containers and Helm charts from AWS ECR Public Gallery and AWS Marketplace on 10 June 2026, with a 1 June brownout for the top 20 ECR repositories. Check the registry in the running workload rather than assuming every failure has the same cause.

When an old workload still runs but a replacement Pod cannot start, compare its image reference, registry access and node cache. Restoring access to a retained artifact can resolve the immediate pull failure. It does not establish that the artifact will receive future fixes.

Identify the exact dependency

Record the chart publisher and version, every image reference including init containers and exporters, image digests, registry credentials and current cache behavior. Check staging on a clean node: a cached image can hide a missing upstream artifact until production reschedules.

Shortlist a replacement by workload

Migration choices and the compatibility work each leaves

Workload	Candidate direction	Check before switching
PostgreSQL	A supported database service, CloudNativePG or another maintained PostgreSQL deployment.	Extension availability, roles, data transfer, client endpoints and the new backup system. Follow the PostgreSQL rehearsal.
Redis or Valkey	A maintained deployment for the selected engine; Valkey publishes its own project chart.	Commands and modules used by clients, topology, persistence format, authentication and failover. Use the Redis and Valkey guide.
MinIO object storage	A maintained S3-compatible service or deployment that fits the required object API behavior.	Versions, metadata, retention, IAM behavior and a copy-and-verify process. Start with the MinIO alternatives comparison.
Stateless application	The application's maintained image and chart, a supported distribution or an internally maintained build.	Entrypoint, UID/GID, configuration paths, health probes, init containers and mounted Secrets.

The Valkey project's chart announcement establishes an upstream deployment option, not compatibility with every Bitnami value or Redis workload. For any candidate, compare the rendered resources and application behavior before treating it as a replacement.

A chart swap is not a migration

Different images can expect different users, directory layouts, environment variables and startup scripts. Different charts can rename Services and Secrets or change StatefulSet selectors. Do not attach the only copy of production data to an arbitrary replacement. Restore a copy into the target and validate the workload contract first.

Build an artifact inventory that survives a node replacement

Include every runtime artifact, not only the main image: initialization jobs, permission-fixing containers, exporters, backup tools and chart hooks can fail independently. For each artifact, record its source, digest, license or access terms, maintenance owner and a tested pull path. Distinguish an image already present on a node from one a new node can retrieve.

Retain the chart archive and the configuration needed to reproduce the installation. Avoid saving live credentials in a public migration record. A private mirror can improve availability and preserve a known artifact, but it does not patch vulnerabilities in that artifact. Assign an update process to every mirrored image rather than treating the mirror as the end of the migration.

For a starting inventory, use kubectl JSONPath to list image references for existing Pods, including init containers:

# Bash; choose the context explicitly. These commands only read Pod metadata.
migration_context=your-reviewed-context
kubectl --context "$migration_context" get pods --all-namespaces \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.initContainers[*]}{.image}{" "}{end}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'

This is a read-only query template, not an executed cluster audit. It lists declared image references, which can be mutable tags; record the resolved image IDs from Pod status separately. Existing Pods do not cover scaled-to-zero workloads, future CronJobs or removed chart hooks. Review those workload templates and retained chart manifests too. Registry credentials belong in your existing secret-management system, not this inventory.

Choose a chart, operator, managed service or your own build

A maintained application chart may be close to the existing deployment but use different value names and defaults. An operator can add application-specific reconciliation, failover and backup integration, while introducing CRDs and a controller lifecycle. A managed service transfers some operations to a provider but adds network, identity, billing and data-export constraints. An internally maintained image gives control at the cost of owning rebuilds, security response and compatibility testing.

Evaluate these options against the team's actual operating capacity. A technically possible self-build is not a sustainable option if no one is responsible for tracking upstream fixes or verifying the resulting image. Conversely, an external support offering needs a concrete artifact-access and update workflow, not just a commercial label in a spreadsheet.

List what the application expects before changing its container

• Startup: initialization scripts, environment variables, entrypoint arguments, probes and shutdown signals.
• Identity: user and group IDs, filesystem permissions, security context, mounted credentials and certificate paths.
• Data: directory layout, application version, storage class, volume ownership and backup format.
• Network: service names, port numbers, TLS expectations, advertised peer addresses and client configuration.
• Operations: metrics endpoints, alert labels, backup jobs, restore procedures and upgrade ordering.

Use explicit acceptance stages

First validate artifact retrieval and a fresh installation. Then restore representative data and run the application's normal operations. Next test restart, failover where relevant, backup and restore. Finally rehearse a migration with the same write-freeze or replication procedure planned for production. Treat these as separate results: a fresh pod starting is not evidence that a populated database will migrate safely.

Define a decision point before writes begin at the destination. Before that point, returning clients to the unchanged source may be straightforward. After it, the source may be stale and an application-specific reconciliation or reverse-migration process is required. State this boundary in the change record so an incident responder does not unintentionally discard successful writes while trying to restore service.

What this guidance establishes

The catalog change and legacy-image maintenance status are documented upstream. Kubedex has not tested a universal image substitution, because the application and image contracts differ. Use the inventory above to turn the broad migration into a set of versioned, testable changes and keep evidence for the exact workload chosen.