Mi VM con Debian 11 sigue funcionando. ¿De verdad tengo que hacer algo?

La VM sigue corriendo y Google Cloud sigue dando soporte a la VM en sí, así que nadie te obliga a moverte esta semana. Lo que se perdió el 31 de agosto de 2026 es el flujo de actualizaciones de seguridad: Debian ya no publica nada para bullseye, y la documentación del ciclo de vida de Compute Engine es explícita en que conseguir las actualizaciones pasa a ser tu responsabilidad. Trátalo como trabajo planificado de este trimestre, no como emergencia, y agéndalo antes de que salga el siguiente aviso serio.

¿Todavía puedo crear una VM nueva desde una imagen de Debian 11?

Por la familia de imágenes, no. La documentación de Google dice que al llegar el fin de soporte la última imagen de la familia se elimina o se marca como obsoleta y la familia deja de servir, aunque todavía puedes referenciar una imagen obsoleta específica con la bandera --image desde la CLI de gcloud o la API REST. Eso es una salida de emergencia para una reconstrucción que no puedes evitar, no un plan.

¿Actualizo en sitio o levanto una VM nueva?

Depende de qué tan bien conozcas la máquina. Si está provisionada desde configuración y puedes enumerar lo que corre en ella, la actualización en sitio que documentan las notas de versión de Debian es directa. Si lleva años editada a mano y nadie sabe qué tiene instalado, levantar una VM nueva desde una familia de imágenes vigente y mover la aplicación suele ser más rápido, y te deja un servidor que sí vas a poder reconstruir la próxima vez.

Fin de soporte de Debian 11 en tus VMs de Google Cloud

Casi ninguna empresa pequeña sabe qué versión de Linux corre en su servidor. Sabe que el sitio está arriba, que el sistema de facturación responde y que nadie entra a esa máquina virtual desde que se fue la persona que la armó. Esa es la escena que más encontramos en Google Cloud: una o dos VMs de Compute Engine, creadas hace años con la imagen que estaba vigente en ese momento, trabajando calladas al fondo del proyecto.

A finales de agosto, muchas de esas máquinas dejaron de recibir actualizaciones de seguridad. Nada se apagó, nada mandó una alerta y el sitio sigue cargando. Justo por eso vale la pena dedicarle una tarde.

Qué cambió y en qué fecha

El equipo de Long Term Support de Debian anunció el 31 de agosto de 2026 que Debian 11, de nombre clave bullseye, llegó al final de su vida útil. La versión salió el 14 de agosto de 2021 y tuvo tres años de soporte regular de Debian hasta el 14 de agosto de 2024, más dos años a cargo del equipo de LTS. Desde septiembre de 2026 ya no hay más actualizaciones de seguridad de parte de Debian. Un subconjunto de paquetes sigue mantenido comercialmente por un tercero bajo Extended LTS, que es un puente, no un destino.

Google Cloud publicó la señal equivalente un par de semanas antes. En la nota de versión con fecha del 19 de agosto de 2026, la familia de imágenes de Debian 11 para Batch quedó marcada como fin de desarrollo, y la razón que da es el fin de soporte de Debian 11 en Compute Engine.

Así que la fecha límite no es de Google ni es la venta de un proveedor. Es la distribución de arriba diciendo que terminó, y todas las nubes que publican imágenes de Debian yendo detrás.

Qué significa de verdad el fin de soporte para una VM que ya está corriendo

Aquí la gente entra en pánico o lo ignora, y las dos reacciones están mal. La documentación del ciclo de vida de los sistemas operativos en Compute Engine es precisa sobre lo que pasa cuando una versión llega al fin de soporte:

La última imagen de la familia se elimina o se marca como obsoleta, y la familia de imágenes ya no sirve para crear VMs nuevas.
Todavía puedes crear una VM desde una imagen obsoleta específica, pero solo referenciándola directamente con la bandera --image desde la CLI de gcloud o la API REST, porque las familias de imágenes no apuntan a imágenes obsoletas.
Las VMs existentes siguen funcionando y siguen siendo elegibles para el soporte de Google Cloud después de esa fecha.
Si un problema se rastrea hasta la versión obsoleta del sistema operativo, es posible que Google no pueda resolverlo, porque el proveedor del sistema operativo ya no le da soporte.
Las actualizaciones corren por tu cuenta, y dependen de lo que la distribución, el proveedor o la comunidad sigan publicando.

Lee dos veces el último punto. Tu VM no se rompe. Lo que se rompe es tu forma de parchar. Cada aviso de seguridad del kernel o de OpenSSL que salga de ahora en adelante es uno que no vas a poder aplicar desde el archivo normal, y la brecha se abre más cada mes que lo dejas así.

A quién le pega en una empresa pequeña o mediana

Por lo que vemos, las máquinas afectadas casi nunca son las que uno tiene en la cabeza. Digamos que una distribuidora de 20 personas en San Salvador se salió del hosting compartido en 2022. Lo que tiene hoy suele ser alguna mezcla de esto:

Una sola VM con el sitio público, muchas veces WordPress detrás de Nginx, creada con la imagen de Debian vigente ese año.
Un servidor de aplicación para un sistema interno, accesible solo dentro de la VPC, que nadie reinicia porque reiniciarlo da miedo.
Una máquina utilitaria chiquita: un jump host, un proxy de base de datos o un servidor de cron que manda facturas y estados de cuenta por correo cada noche.
Imágenes base de contenedores hechas sobre bullseye, guardadas en Artifact Registry y desplegadas en Cloud Run, que heredan el mismo archivo de paquetes vencido.

Esa máquina de cron merece renglón aparte. Cuando un servidor que manda correo se queda sin parches, el riesgo no es solo que lo comprometan. Un stack de correo desactualizado termina enviando con una configuración vieja de TLS o, peor, retransmitiendo correo ajeno, y ahí ya no estás atendiendo un problema de parches sino uno de entregabilidad. Si eso ya te está pasando, empieza por entregabilidad de correo y trata el sistema operativo como la causa de fondo.

Qué revisamos primero en un proyecto de cliente

Antes de tocar nada, armamos la lista. Adivinar cuáles VMs están en bullseye es la forma más segura de dejar por fuera justo la que importa.

Compute Engine guarda la imagen con la que se creó cada disco. Empieza por la instancia, que enlista sus discos conectados:

gcloud compute instances describe VM_NAME --zone=ZONE

Luego pregúntale al disco de dónde viene. En una VM creada desde una imagen pública del sistema operativo, esto devuelve la imagen de origen; en una creada desde una imagen de disco, devuelve el disco de origen:

gcloud compute disks describe DISK_NAME \
  --zone=ZONE \
  --format="get(SOURCE)"

La imagen de origen es el historial, no la verdad. Una VM creada con una imagen de Debian 11 pudo haberse actualizado ya, y otra creada con algo distinto pudo haber sido arrastrada a bullseye a mano. Por eso confirmamos en la propia máquina leyendo /etc/os-release, que es donde el sistema en ejecución declara su versión.

Después anotamos qué hace realmente cada máquina, porque eso es lo que define el plan: qué servicios arrancan solos, qué cron jobs hay y qué tocan, si la aplicación depende de una versión específica del runtime del sistema, y qué repositorios APT de terceros están configurados. Ese último es el dolor de siempre. Un repositorio que solo publica para bullseye detiene la actualización en seco, y enterarte a medio camino arruina la noche.

La actualización, en el orden en que la hacemos

1. Toma un snapshot del disco de arranque y comprueba que puedes restaurarlo. No una captura de pantalla de la consola, un snapshot de verdad:

gcloud compute disks snapshot DISK_NAME --snapshot-name=SNAPSHOT_NAME

La vuelta atrás consiste en crear un disco desde ese snapshot, algo que solo se puede hacer al momento de crearlo:

gcloud compute disks create NEW_DISK_NAME --source-snapshot SNAPSHOT_NAME

2. Decide entre actualizar en sitio o reconstruir. En una máquina editada a mano durante cuatro años, levantar una VM nueva desde una familia de imágenes vigente y mover la aplicación suele ser más rápido y siempre queda más limpio, porque terminas con un servidor que puedes volver a construir. Elegimos la actualización en sitio cuando la máquina está bien entendida, está provisionada desde configuración, o está demasiado enredada como para reproducirla dentro de la ventana de mantenimiento.

3. Si actualizas en sitio, sigue las notas de versión de Debian. Debian documenta la actualización de una versión a la siguiente, y el capítulo de bookworm cubre las actualizaciones desde bullseye. La forma, en orden: quita bullseye-backports y las entradas de terceros de tus listas de fuentes de APT, deja el sistema completamente al día todavía en bullseye, y hasta entonces apunta las fuentes a bookworm.

sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list

No dejes entradas de bullseye y bookworm conviviendo. Después corre la actualización en la secuencia documentada, que hace el paso mínimo antes del completo:

export LC_ALL=C
apt update
apt upgrade --without-new-pkgs
apt full-upgrade

Si la actualización se detiene con errores de configuración, las notas de versión de Debian dan la salida: corre apt full-upgrade -o APT::Immediate-Configure=0 en su lugar. Cuenta con que te va a preguntar por archivos de configuración modificados, y con responder cada pregunta con el archivo abierto en otra ventana. Esta es la parte que no se automatiza en una máquina que te importa.

4. Reinicia y verifica como si fueras de afuera. Servicios arriba al arranque, el sitio respondiendo por HTTPS con certificado válido, los cron jobs corriendo con su usuario real, los logs escribiéndose, y el correo que sale de esa máquina todavía autenticando. Verifica desde fuera de la VPC, no desde adentro de la máquina que acabas de cambiar.

5. Agenda el siguiente salto ahora, no en dos años. Debian 12 bookworm es la versión oldstable actual y es donde el equipo de LTS está dando soporte de seguridad hoy; Debian 13 trixie es la versión estable actual. Quedarte en bookworm es una parada legítima, y la fecha del salto a trixie va en este mismo cambio, mientras los detalles están frescos.

Notas de costo y de riesgo

El costo directo de este trabajo es bajo y es sobre todo tu tiempo. Lo que conviene saber:

Los snapshots se cobran como datos almacenados mientras los conserves. Mantenlos durante la ventana de vuelta atrás y bórralos a propósito, no por accidente.
Una actualización en sitio necesita una ventana de mantenimiento real. Cuenta con que la aplicación va a estar abajo y avísale a quien contesta el teléfono.
Quedarte en una imagen sin soporte no es un problema de facturación, es un problema de soporte y de seguridad: la VM sigue corriendo y Google sigue dando soporte a la VM, pero el sistema operativo de abajo ya no tiene quien lo publique.
El Extended LTS comercial de bullseye cubre solo un subconjunto de paquetes. Te compra un trimestre de aire para una máquina que de verdad no se puede mover todavía. No sustituye la actualización.
La falla que más vemos no es la actualización en sí. Es un repositorio APT de terceros o una versión de runtime fijada que nadie documentó, descubierta a las once de la noche. El paso de inventario de arriba es lo que evita eso.

Cómo ayuda Guanacos Tech

Lo hacemos como un trabajo acotado: inventariamos cada VM y cada imagen base de contenedor del proyecto, te decimos con honestidad cuáles conviene actualizar y cuáles conviene reconstruir, tomamos los snapshots, ejecutamos el cambio en la ventana que elijas y verificamos desde afuera. Te queda un documento corto que dice qué es cada máquina, qué corre y cuándo vuelve a necesitar atención, para que la siguiente versión no llegue de sorpresa.

Si tienes una VM en Compute Engine y no sabes con certeza qué está corriendo, ese es el punto de partida normal, y averiguarlo toma minutos. Mira lo que hacemos en Google Cloud, lee cómo trabajamos, o agenda una llamada y lo vemos contigo.

Debian 11 quedó sin soporte: qué hacer con tus VMs en Google Cloud