Actualizar un stack Docker Compose en producción

Cuando una imagen Docker etiquetada como latest se actualiza en el registry, tu docker compose pull la descarga en silencio. Sin advertencia, sin diff. Reinicias el stack y descubres que el nuevo contenedor no puede leer los datos que dejó el anterior.

Es exactamente el riesgo con Meilisearch. La base de datos lleva el número de versión del motor que la escribió: al subir de versión, el nuevo motor se niega a abrirla mientras no se le pida explícitamente migrarla con --upgrade-db (o la variable MEILI_UPGRADE_DB). Con una política de reinicio, el contenedor entra entonces en crash-loop. Y una vez migrada la base, la imagen anterior ya no puede abrirla: Meilisearch no admite la vuelta atrás. La única red de seguridad limpia es un dump o un snapshot del volumen creado antes de la actualización — imposible una vez migrada la base o bloqueado el contenedor.

El tag latest no resuelve a la misma imagen según el momento del pull. Dos desarrolladores que ejecutan docker compose pull con doce horas de diferencia pueden descargar versiones distintas. En un stack de producción, esta ambigüedad es inaceptable. La solución no es evitar las actualizaciones: es controlar explícitamente qué versión está en ejecución y decidir conscientemente cuándo pasar a la siguiente.

La primera acción, antes de cualquier actualización, es reemplazar cada image: getmeili/meilisearch:latest o image: supabase/postgres por una versión explícita.

Dos formas son aceptables:

- Tag de versión: image: getmeili/meilisearch:v1.53.0 — legible, versionable en git, fácil de parchear.
- Digest SHA256: image: getmeili/meilisearch@sha256:abc123… — inmutable, garantiza que descargas exactamente el mismo artefacto en cada redespliegue, incluso si el tag fue sobreescrito.

Para obtener el digest de una imagen ya en ejecución:

docker inspect --format='{{index .RepoDigests 0}}' getmeili/meilisearch:v1.53.0

Una vez fijadas tus imágenes, haz commit del docker-compose.yml en git. Cada bump de versión se convierte en un commit, lo que te da un historial claro y un rollback trivial (git revert + docker compose up -d).

Estos cuatro ejemplos ilustran por qué el protocolo anterior no es teórico.

Meilisearch (al subir de versión): un motor más reciente se niega a abrir una base escrita por una versión anterior, con Your database version (…) is incompatible with your current engine version, mientras no se pase --upgrade-db. Esa migración puede cambiar el formato en disco: en la v1.37.0 (marzo de 2026), los índices vectoriales aún en formato arroy se convirtieron al nuevo almacén HNSW (hannoy). Y la vuelta atrás no está soportada (Downgrade is not supported). La única salida limpia tras un fallo es haber exportado un dump antes de la actualización y luego importarlo (meilisearch --db-path /meili_data --import-dump /backup.dump) — algo posible solo si exportaste antes de actualizar.

Supabase Docker PostgreSQL 15 → 17 (PG 17 por defecto desde el 17 de junio de 2026): el contenedor supabase/postgres:17 no puede leer un volumen inicializado por PG 15. Supabase documenta explícitamente que el salto requiere un pg_upgrade mediante un script dedicado — el proceso de inicialización del contenedor no lo hace automáticamente. Sin una migración previa, la base de datos no arranca.

Langfuse v3 → v4 (v4.0.0 publicada el 29 de julio de 2026): la v4 abandona los endpoints de ingesta batch legacy en favor de OpenTelemetry. Los SDKs Python v2 y anteriores y los SDKs JS/TS v3 y anteriores son rechazados en la ingesta en cuanto el stack v4 funciona en su modo de escritura por defecto (events_only); los modos legacy y dual permiten escalonar la migración. Si tus servicios cliente no han migrado antes de la actualización del servidor, pierden silenciosamente todos sus trazados.

NocoDB (serie 2026.09): ninguna base rota, pero sí un cambio incompatible anunciado con antelación. Las notas de la 2026.09.0 recuerdan que las fechas devueltas por la API REST, los webhooks y las exportaciones pasarán de la precisión de segundo a la de milisegundo en PostgreSQL y SQLite en una próxima versión. Un cliente que lea las fechas con un formato estricto fallará sin que el servidor avise de nada — justo lo que la lectura de las notas de versión permite anticipar. Otra trampa, independiente de la versión: una instalación con bind-mounts (./postgres, ./nocodb) cuya ruta de montaje cambia entre dos despliegues arranca sobre una base vacía. Los volúmenes nombrados evitan esta deriva.

Un protocolo que queda en una guía no sirve de nada. Para aplicarlo sistemáticamente, externaliza la versión en un archivo .env versionado en git:

# .env
MEILISEARCH_VERSION=v1.53.0
POSTGRES_VERSION=15.6

# docker-compose.yml
services:
  meilisearch:
    image: getmeili/meilisearch:${MEILISEARCH_VERSION}

Actualizar una versión se convierte entonces en un único commit sobre .env — legible en git log, reversible con git revert, y desplegable por CI/CD sin modificar el archivo Compose principal.

Para agencias que gestionan múltiples stacks de clientes, crea un archivo CHANGELOG_INFRA.md por cliente: cada actualización queda registrada con la versión anterior, la fecha, el backup realizado y el resultado. Esto también te protege contractualmente ante un eventual incidente posterior.