El error docker.io/bitnami/postgresql:16: not found significa que esa etiqueta ya no existe en Docker Hub: Bitnami solo publica latest en docker.io/bitnami, y en 8 de los 14 repositorios que consulté ni eso. El parche inmediato es cambiar bitnami/ por bitnamilegacy/ en tu compose o en los valores de Helm. La salida definitiva es pasar a la imagen oficial, y ahí hay tres detalles que te pueden dejar una base de datos vacía. Lo probé el 27 de octubre de 2026 en Linux arm64 con Docker 29.5.2, Compose v2.40.3 y Helm v4.3.1, con 50 000 filas en PostgreSQL y 10 000 claves en Redis. Tienes la versión en inglés de esta guía.

Puntos clave

  • De 14 repositorios populares de docker.io/bitnami que consulté, 6 solo tienen la etiqueta latest y 8 no tienen ninguna, entre ellos kafka, rabbitmq, mysql y minio.
  • bitnami/postgresql:latest ya es PostgreSQL 18.6 sobre Photon OS: si tus datos son de la 16, el servidor se para con database files are incompatible with server.
  • bitnamilegacy/* se descarga, pero está congelado desde agosto de 2025: bitnamilegacy/postgresql:16 es la 16.6, y la oficial postgres:16 va por la 16.15.
  • Para pasar a postgres:16 sin perder datos, apunta PGDATA a /bitnami/postgresql/data y crea postgresql.conf y pg_hba.conf, porque Bitnami no los guarda en el volumen.
  • Con Redis, la imagen oficial arranca con 0 claves si no le pasas --appendonly yes: Bitnami guarda los datos solo en el fichero AOF.

¿Qué significa el error bitnami/postgresql not found?

Significa que Docker Hub no tiene un manifiesto para la etiqueta que pides, y no es un problema de red ni de credenciales. Estos son los mensajes exactos que obtuve el 27 de octubre de 2026, primero con docker pull y luego con docker compose up:

$ docker pull bitnami/postgresql:16
Error response from daemon: failed to resolve reference
"docker.io/bitnami/postgresql:16": docker.io/bitnami/postgresql:16:
not found

$ docker compose up -d
 db Pulling
 db Error failed to resolve reference "docker.io/bitnami/postgresql:16":
 docker.io/bitnami/postgresql:16: not found

En tu terminal cada mensaje sale en una línea; aquí lo he partido para que quepa. Ese texto es el del almacén de imágenes de containerd, el predeterminado en Docker 29. Con el almacén clásico, el mismo fallo se lee manifest for bitnami/moodle:latest not found: manifest unknown: manifest unknown, según una incidencia de bitnami/containers sobre Moodle[1] con comentarios hasta octubre de 2026. bitnami/redis:7.4, bitnami/kafka:3.9 y bitnami/kafka:latest fallan igual.

¿Por qué desaparecieron las imágenes de Bitnami?

Porque Broadcom movió el catálogo gratuito a un repositorio congelado y reservó las imágenes mantenidas para su suscripción Bitnami Secure Images. El aviso de Bitnami en GitHub[2] fijó el borrado de docker.io/bitnami para el 29 de septiembre de 2025, tras tres apagones de prueba. Sobre el destino de las imágenes antiguas, el aviso es claro: "This legacy catalog will receive no further updates or support and should only be used for temporary migration purposes".

Un año después, el error sigue apareciendo. En agosto de 2026 alguien abrió la incidencia de etiquetas por versión no resolubles[3] porque bitnami/postgresql:14 fallaba mientras latest funcionaba. La búsqueda de GitHub devuelve 1 200 incidencias y PRs con «bitnamilegacy» creadas desde el 1 de septiembre de 2026. Este es el estado que leí en la API de Docker Hub:

Repositorio Etiquetas en bitnami/ Última subida a bitnamilegacy/
postgresql, redis, mariadb, mongodb, nginx solo latest 22 a 29 de agosto de 2025
kafka, rabbitmq, mysql, minio ninguna 13 a 28 de agosto de 2025
elasticsearch, etcd, zookeeper, keycloak ninguna 20 a 27 de agosto de 2025

El latest que queda es la imagen de prueba de Bitnami Secure Images. En mi descarga, bitnami/postgresql:latest era PostgreSQL 18.6 y bitnami/redis:latest era Redis 8.10.3, ambas sobre Photon OS 5.

¿Por qué no basta con cambiar a bitnami/postgresql:latest?

Porque latest salta de versión mayor y PostgreSQL no abre datos de otra versión mayor. Lo comprobé sobre un volumen creado con la 16:

FATAL:  database files are incompatible with server
DETAIL:  The data directory was initialized by PostgreSQL version 16,
which is not compatible with this version 18.6.

No se pierde nada, porque el servidor se para antes de escribir. Aun así, una etiqueta flotante en una base de datos te expone a este salto en cada docker compose pull. Usa latest de Bitnami solo si partes de cero.

Arreglo inmediato: cambiar a bitnamilegacy

Cambia el espacio de nombres en la línea image: y conserva la etiqueta. bitnamilegacy tiene las mismas imágenes con los mismos usuarios, variables y rutas, así que tu volumen arranca tal cual:

services:
  db:
    image: bitnamilegacy/postgresql:16
    environment:
      POSTGRESQL_USERNAME: app
      POSTGRESQL_PASSWORD: ${POSTGRESQL_PASSWORD}
      POSTGRESQL_DATABASE: appdb
    volumes:
      - pgdata:/bitnami/postgresql
  cache:
    image: bitnamilegacy/redis:7.4
    environment:
      REDIS_PASSWORD: ${REDIS_PASSWORD}
    volumes:
      - redisdata:/bitnami/redis/data
volumes:
  pgdata:
  redisdata:

Con este compose creé los datos de la prueba: una tabla pedidos de 50 000 filas y 10 000 claves sesion:* en Redis.

Ten en cuenta lo que compras con este parche. La etiqueta 16 de bitnamilegacy es PostgreSQL 16.6, compilada el 3 de diciembre de 2024, y la oficial va nueve versiones menores por delante. Úsala para que el servicio vuelva a arrancar hoy y planifica la migración de la sección siguiente. Hay al menos 18,9 millones de descargas de bitnamilegacy/postgresql que siguen en este punto, según el contador de Docker Hub para bitnamilegacy[4].

¿Cómo migrar PostgreSQL de Bitnami a la imagen oficial?

La forma de menor riesgo es volcar con pg_dump y restaurar en la imagen oficial; la otra es reutilizar el volumen con tres ajustes. Antes de cualquiera de las dos, saca un volcado desde el contenedor de bitnamilegacy que ya funciona:

docker compose exec -T -e PGPASSWORD=tu_clave_de_app db \
  pg_dump -h 127.0.0.1 -U app -d appdb -Fc > appdb.dump

Dos errores que te dejan la base vacía o parada

El primero es montar el volumen en /var/lib/postgresql. Bitnami guarda los datos en el subdirectorio data, que coincide con el VOLUME /var/lib/postgresql/data de la imagen postgres:16. Docker monta encima un volumen anónimo vacío, el script de entrada ejecuta initdb y obtienes un servidor sano sin tu base: database "appdb" does not exist. Tus datos siguen en el volumen, pero no los ves.

El segundo aparece al apuntar PGDATA al directorio correcto. Bitnami guarda postgresql.conf y pg_hba.conf en /opt/bitnami/postgresql/conf, dentro de la imagen, y el volumen no los tiene:

PostgreSQL Database directory appears to contain a database;
Skipping initialization

postgres: could not access the server configuration file
"/bitnami/postgresql/data/postgresql.conf": No such file or directory

Reutilizar el volumen con la imagen postgres:16

Crea los dos ficheros con un contenedor desechable de la imagen oficial. El primero copia la configuración de ejemplo y abre la escucha a la red de Docker. El segundo replica las reglas que pone la imagen oficial: confianza en el socket local y contraseña SCRAM para el resto:

docker compose stop db
docker run --rm -v mi_proyecto_pgdata:/bitnami/postgresql postgres:16 sh -c '
D=/bitnami/postgresql/data
cp /usr/share/postgresql/16/postgresql.conf.sample $D/postgresql.conf
echo "listen_addresses = '"'*'"'" >> $D/postgresql.conf
printf "local all all trust\nhost all all 127.0.0.1/32 trust\n" > $D/pg_hba.conf
echo "host all all all scram-sha-256" >> $D/pg_hba.conf
chown 999:999 $D/postgresql.conf $D/pg_hba.conf'

Cambia mi_proyecto_pgdata por el nombre real del volumen, que ves con docker volume ls. Después cambia el servicio. POSTGRES_PASSWORD solo se usa al crear una base nueva, así que aquí no cambia nada: el usuario app conserva la contraseña que tenía:

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: ${POSTGRESQL_PASSWORD}
      PGDATA: /bitnami/postgresql/data
    volumes:
      - pgdata:/bitnami/postgresql

Con eso arrancó PostgreSQL 16.15 sobre el volumen de la 16.6, con las 50 000 filas y la misma suma MD5 de todo su contenido. El script de entrada cambió el propietario de los ficheros del usuario 1001 de Bitnami al 999 de la imagen oficial. Cada consulta devolvió además este aviso:

WARNING:  database "appdb" has a collation version mismatch
DETAIL:  The database was created using collation version 2.36,
but the operating system provides version 2.41.

La imagen de Bitnami usaba Debian 12 con glibc 2.36 y la oficial usa Debian 13 con glibc 2.41, que puede ordenar texto de otra forma. Reconstruye los índices y registra la versión nueva, como indica la documentación de ALTER DATABASE[5]. Repite el ALTER en postgres y template1:

docker compose exec db psql -U postgres -d appdb \
  -c "REINDEX DATABASE appdb" \
  -c "ALTER DATABASE appdb REFRESH COLLATION VERSION"

Restaurar en postgres:18 desde el volcado

Si vas a cambiar de versión mayor, restaura el volcado en una base nueva. En la imagen postgres:18 el volumen se monta en /var/lib/postgresql, y los datos van a /var/lib/postgresql/18/docker. Si la montas en la ruta antigua, la imagen se niega a arrancar con Error: in 18+, these Docker images are configured to store database data in a format which is compatible with "pg_ctlcluster", por el cambio del PR 1259 de docker-library/postgres[6].

Con el montaje correcto, pg_restore --no-owner cargó las 50 000 filas en PostgreSQL 18.6 con la misma suma MD5. Las novedades de esa rama las tienes en las novedades de PostgreSQL 19 probadas en Docker, que incluye el salto con pg_upgrade desde la 18.

¿Cómo migrar Redis de Bitnami a la imagen oficial?

Monta el mismo volumen en /data y activa AOF, porque Bitnami arranca Redis con appendonly yes y el volumen solo tiene el directorio appendonlydir. Mi primer intento, con redis:7.4 y solo --requirepass, arrancó sin errores y con dbsize igual a 0.

La imagen oficial usa instantáneas RDB por defecto, no encontró dump.rdb y empezó vacía. Los ficheros AOF seguían intactos al lado. El servicio que funcionó es este:

  cache:
    image: redis:7.4
    command: redis-server --appendonly yes --requirepass ${REDIS_PASSWORD}
    volumes:
      - redisdata:/data

Con él, Redis 7.4.12 registró DB loaded from append only file y devolvió las 10 000 claves. La guía de persistencia de Redis[7] explica la diferencia entre RDB y AOF. No escribas en el Redis vacío antes de corregir el arranque, porque su siguiente instantánea no tendrá tus datos. Si piensas cambiar también de motor, la migración real de Redis a Valkey parte del mismo punto.

¿Cómo se arregla en un chart de Helm de Bitnami?

Sobrescribe el repositorio de cada imagen del chart con su copia de bitnamilegacy. Un chart antiguo apunta a etiquetas que ya no existen: la versión 16.7.27 de bitnamicharts/postgresql pide docker.io/bitnami/postgresql:17.6.0-debian-12-r4, que da not found, así que el pod se queda sin imagen. El chart actual, la 18.12.16, pide bitnami/postgresql:latest, que te devuelve al salto a la 18.6. Estos --set mantienen la versión del chart; en una release ya instalada, pasa los mismos a helm upgrade:

helm install mi-postgres \
  oci://registry-1.docker.io/bitnamicharts/postgresql --version 16.7.27 \
  --set image.repository=bitnamilegacy/postgresql \
  --set volumePermissions.image.repository=bitnamilegacy/os-shell \
  --set metrics.image.repository=bitnamilegacy/postgres-exporter

El chart reconoce bitnamilegacy y solo imprime un WARNING: Original containers have been substituted. Si pones una imagen ajena, como library/postgres, la instalación falla en NOTES.txt con Error: INSTALLATION FAILED hasta que añades global.security.allowInsecureImages=true. No lo hagas para usar la imagen oficial dentro del chart: sus variables y rutas son las de Bitnami. Lo comprobé con helm install --dry-run=client, sin desplegar en un clúster.

¿Qué hago con Kafka, RabbitMQ y las imágenes sin latest?

Para esas no hay imagen de Bitnami que descargar sin suscripción, así que la elección es bitnamilegacy o el proyecto oficial. Las alternativas oficiales que vi publicadas el 27 de octubre de 2026 son estas:

  • Kafka: apache/kafka, con la 4.4.0 como última etiqueta
  • RabbitMQ: rabbitmq, con la 4.3.7
  • MariaDB: mariadb, con la 12.3.3
  • MinIO: no hay imagen oficial; la guía del error pull access denied de MinIO prueba tres sustitutos

De estas solo descargué apache/kafka; no migré datos de Kafka ni de RabbitMQ. Cada una tiene sus propias variables de entorno y rutas, así que trata el cambio como una migración y no como un cambio de etiqueta. Antes de empezar, copia tus volúmenes como explica la guía de volúmenes y bind mounts en Docker.

Preguntas frecuentes

¿Se arregla con docker login?

No. Docker Hub ya no tiene esas etiquetas para nadie, y el error es not found, no unauthorized. Las versiones mantenidas están en el registro de Bitnami Secure Images, que exige suscripción de pago. No lo probé con una cuenta.

¿Puedo volver a bitnamilegacy después de probar la imagen oficial?

Sí, pero tienes que deshacer dos cambios. La imagen oficial cambió los ficheros al usuario 999, y bitnamilegacy falló con ls: cannot open directory '/bitnami/postgresql/data': Permission denied. Un chown -R 1001:0 desde un contenedor desechable lo arregló. Además, Bitnami borró al arrancar el postgresql.conf y el pg_hba.conf que había creado, así que repite ese paso si vuelves a la oficial.

¿Cuánto tiempo seguirá disponible bitnamilegacy?

Bitnami no ha publicado fecha de cierre. El aviso de 2025 lo presenta como un recurso temporal, y no recibe parches desde agosto de 2025. Copia las imágenes que uses a tu propio registro privado de imágenes Docker para no depender de su permanencia.

Conclusión

docker.io/bitnami/postgresql:16: not found no tiene arreglo desde tu máquina: la etiqueta ya no existe y latest es otra versión mayor. Cambia hoy a bitnamilegacy para que el servicio arranque.

Esta semana, saca un pg_dump y pasa a postgres con PGDATA y los dos ficheros de configuración, o restaura en postgres:18. Con Redis, añade --appendonly yes. En ambos casos, cuenta filas y claves antes y después.

Fuentes: [1] Bitnami, aviso de cambios en el catálogo[2], [2] bitnami/containers, incidencia 96169 sobre etiquetas no resolubles[3], [3] bitnami/containers, incidencia 90492 sobre bitnami/moodle[1], [4] Docker Hub, espacio bitnamilegacy[4], [5] docker-library/postgres, PR 1259 sobre PGDATA en la 18[6], [6] bitnami/charts, incidencia 30850 sobre imágenes sustituidas[8], [7] PostgreSQL, documentación de ALTER DATABASE[5], [8] Redis, guía de persistencia[7].

Fuentes

  1. incidencia de bitnami/containers sobre Moodle
  2. aviso de Bitnami en GitHub
  3. incidencia de etiquetas por versión no resolubles
  4. Docker Hub para bitnamilegacy
  5. documentación de ALTER DATABASE
  6. PR 1259 de docker-library/postgres
  7. guía de persistencia de Redis
  8. bitnami/charts, incidencia 30850 sobre imágenes sustituidas