Skip to main content

Bitnami image deprecation (August 2025)

If you deploy Appsmith on Kubernetes using our Helm chart, a recent upstream change may affect your deployment.

Bitnami announced that on August 28, 2025, many versioned images hosted at docker.io/bitnami will be moved to a read‑only docker.io/bitnamilegacy repository. Appsmith’s Helm chart includes Bitnami‑packaged images for the optional in‑cluster databases (MongoDB and PostgreSQL), so some deployments will be impacted when a MongoDB or PostgreSQL pod is replaced during a node replacement or other cluster maintenance. This can cause an outage of your Appsmith deployment.

As of Appsmith Helm chart version 3.6.4, we are switching the defaults to use the docker.io/bitnamilegacy repositories. This is a stopgap solution while we evaluate options for a long-term solution for this change.

How do I know if I’m affected​

This change affects only Kubernetes deployments installed with Helm that still use the in‑cluster databases from the chart’s default values. You are not affected if you:

  • Use external/managed databases (for example, MongoDB Atlas or an external PostgreSQL) and have configured Appsmith to connect to them
  • Deployed Appsmith on a platform other than Kubernetes
  • Installed or reinstalled with a chart version that no longer relies on these Bitnami images (post‑August 2025 guidance)

Proactive check​

To proactively check your deployment, verify whether the MongoDB or PostgreSQL pods are using images from docker.io/bitnami/*.

  1. Locate the namespace your deployment is running in and set it in an environment variable for reuse:
# Find the release and namespace
helm list -A | grep appsmith

# Example: set the namespace (replace with your actual namespace)
NAMESPACE=appsmith

If multiple namespaces are returned, repeat the following checks for each one.

  1. Check if your deployment is using the default in‑cluster databases (MongoDB, PostgreSQL):
kubectl get pods -n "$NAMESPACE"

# Example output
NAME                         READY   STATUS    RESTARTS      AGE
appsmith-0                   1/1     Running   3 (19d ago)   59d
appsmith-mongodb-0           1/1     Running   0             22h
appsmith-mongodb-1           1/1     Running   0             22h
appsmith-mongodb-arbiter-0   1/1     Running   0             22h
appsmith-postgresql-0        1/1     Running   0             22h

If you do not see pods named with mongodb or postgresql, you are likely not using the in‑cluster databases and can skip the rest.

If you do see these pods, check whether their images are pulled from docker.io/bitnami:

# MongoDB
kubectl get statefulset -n "$NAMESPACE" -l app.kubernetes.io/name=mongodb \
  -o jsonpath='{range .items[*]}{.metadata.name}={.spec.template.spec.containers[0].image}{"\n"}{end}' | grep 'docker.io/bitnami/' || true

# PostgreSQL
kubectl get statefulset -n "$NAMESPACE" -l app.kubernetes.io/name=postgresql \
  -o jsonpath='{range .items[*]}{.metadata.name}={.spec.template.spec.containers[0].image}{"\n"}{end}' | grep 'docker.io/bitnami/' || true

If any command returns an image reference from docker.io/bitnami/..., you should take action to avoid future image pull errors after August 28, 2025 (for example, ImagePullBackOff).

Deployment is broken (after August 28, 2025)​

If your Appsmith deployment is currently down and shows MongoDB or PostgreSQL pods stuck with ImagePullBackOff or ErrImagePull (post‑August 28, 2025), you are likely already affected.

Common symptoms:

  • ImagePullBackOff or ErrImagePull in kubectl get pods for MongoDB or PostgreSQL pods
  • Failed to pull image, pull access denied, or insufficient_scope: authorization failed in kubectl describe pod

For example, your pod list might show:

pod/appsmith-ee-mongodb-0           0/1     ImagePullBackOff   0              21m

And kubectl describe pod might include:

Warning  Failed     2s (x2 over 16s)  kubelet            Failed to pull image "docker.io/bitnami/mongodb:6.0.13": failed to pull and unpack image "docker.io/bitnami/mongodb:6.0.13": failed to resolve reference "docker.io/bitnami/mongodb:6.0.13": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

If you are seeing something similar to the above, proceed to the next section to fix it.

What to do next​

  • If your deployment is still functional, take a backup of the instance
  • Upgrade to the latest Appsmith Helm chart version, at least 3.6.4. This release updates the in‑cluster MongoDB and PostgreSQL image repositories to docker.io/bitnamilegacy to ensure continued pulls after August 28, 2025. Follow the Kubernetes steps here: Update Appsmith.
  • After upgrading, re‑run the proactive image checks above to confirm images reference docker.io/bitnamilegacy/*.

If the deployment is still down and after performing the Helm upgrade, you may need to clear the current broken pod in the StatefulSet. Force a rollout of the MongoDB and PostgreSQL StatefulSets:

kubectl rollout restart statefulset/appsmith-ee-mongodb -n "$NAMESPACE"
kubectl rollout restart statefulset/appsmith-ee-mongodb-arbiter -n "$NAMESPACE"
kubectl rollout restart statefulset/appsmith-ee-postgresql -n "$NAMESPACE"

For further assistance, contact Appsmith support using the chat widget in the bottom‑right corner of this page.

See also​