Probado con Docker Engine 29.8.1 · Compose 5.5.1 · Debian 13.6 / 12.15 (arm64) · verificado

Actualizado: 2026-09-16

Instalar Docker en Debian 13 parece un trámite mecánico: copias cuatro comandos y listo. Pero hay decisiones ocultas en ese proceso que condicionan los próximos doce meses de operación. Qué repositorio usar, cómo gestionar los permisos y qué poner en daemon.json desde el primer arranque son preguntas con consecuencias reales en cuanto la máquina pasa de experimento a servicio expuesto. Hemos revisado esta guía el 16 de septiembre de 2026 con Debian 13 «Trixie» y Docker Engine 29.8.1.

Puntos clave

  • Debian 13 empaqueta docker.io 26.1.5 y Docker publicó la 29.8.1 el 15 de septiembre de 2026: el repositorio oficial de Docker es la única elección razonable para producción.

  • La instalación estándar requiere cinco paquetes: docker-ce, docker-ce-cli, containerd.io, docker-buildx-plugin y docker-compose-plugin.

  • Pertenecer al grupo docker equivale a tener root en la máquina; evalúa Docker rootless en servidores compartidos.

  • Configura rotación de logs y live-restore en daemon.json desde el primer día, y aplícalos con un reinicio del servicio, no con un reload.

  • Debian 12 sigue admitido por Docker con los mismos comandos, aunque ya solo tiene soporte a largo plazo.

  • docker run hello-world que imprime el mensaje de bienvenida es el principio, no el final.

Por qué no usar el paquete de Debian

Debian incluye docker.io en sus repositorios, y para jugar en un portátil es aceptable. El propio wiki de Debian sobre Docker[1] lo deja claro: docker.io es el paquete de la distribución y docker-ce es el equivalente que mantiene el proyecto Docker. Cuando la máquina hace trabajo real, el paquete de la distribución se queda corto:

  • Debian 13 empaqueta la versión 26.1.5[2], tres versiones mayores por detrás de la 29.8.1.

  • Debian adapta los parches de seguridad a la 26.1 (la revisión del 13 de agosto de 2026[3] corrige seis CVE), pero las novedades de las versiones 27 a 29 no llegan.

  • containerd (1.7.24) y runc (1.1.15) son paquetes aparte de Debian, mientras Docker publica su containerd.io (2.3.5) junto al motor.

El repositorio oficial de Docker resuelve los tres problemas. El paquete de la 29.8.1 para Debian 13 llegó a su directorio de paquetes[4] el mismo 15 de septiembre, y motor, cliente, containerd y plugins se actualizan desde ese repositorio. Este tutorial sigue la guía oficial de instalación para Debian[5] sobre Debian 13 «Trixie», publicado el 9 de agosto de 2025 según la página oficial de la versión[6]. El plugin docker compose viene empaquetado junto al motor, eliminando el baile histórico entre docker-compose con guion y docker compose con espacio.

Preparar el terreno

Antes de añadir nada nuevo, retira los siete paquetes no oficiales que la guía de Docker marca como conflictivos:

old="docker.io docker-compose docker-doc docker-buildx podman-docker"
sudo apt remove $(dpkg --get-selections $old containerd runc | cut -f1)

dpkg --get-selections filtra los que tengas instalados; si no hay ninguno, avisa con no packages found matching y APT no borra nada. La desinstalación no toca imágenes ni volúmenes en /var/lib/docker y /var/lib/containerd. Con el sistema limpio, actualiza APT e instala las dos dependencias del repositorio firmado:

sudo apt update
sudo apt install -y ca-certificates curl

Ya no hace falta gnupg: Docker publica la clave en texto ASCII y la guardas tal cual, sin pasarla por gpg --dearmor.

Clave GPG y repositorio

Debian guarda las claves de repositorios de terceros en /etc/apt/keyrings/, un fichero por repositorio. El viejo apt-key add ya no existe en el apt 3.0.3 de Debian 13 (en Debian 12 sigue en /usr/bin/apt-key), y su clave global valía para cualquier repositorio, lo que rompía el aislamiento de APT.

key=/etc/apt/keyrings/docker.asc
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o $key
sudo chmod a+r $key

Declara el repositorio en formato deb822, el que usan las notas de publicación de Debian 13[7] en lugar de las líneas deb de sources.list. El intérprete sustituye el nombre en clave de la versión y la arquitectura antes de escribir el fichero:

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update

En la prueba sobre arm64, el fichero quedó con Suites: trixie y Architectures: arm64. La directiva Signed-By: hace la clave exclusiva de ese repositorio: APT solo aceptará firmas de Docker para paquetes de download.docker.com.

Logotipo de Bash, el intérprete de comandos con el que ejecutamos todos los pasos de instalación de Docker en Debian

Instalar los paquetes correctos

Docker no es un único binario sino un conjunto de piezas con funciones distintas. La variable solo sirve para que la orden quepa en una línea:

pkgs="docker-ce docker-ce-cli containerd.io"
sudo apt install -y $pkgs docker-buildx-plugin docker-compose-plugin

Qué hace cada uno, con la versión que instaló APT el 16 de septiembre de 2026:

  • docker-ce (29.8.1): el daemon dockerd que escucha en el socket Unix y orquesta contenedores.

  • docker-ce-cli (29.8.1): el cliente docker que habla con el daemon.

  • containerd.io (2.3.5): el runtime de bajo nivel que lanza los contenedores, con su propio runc 1.5.1.

  • docker-buildx-plugin (0.37.1): construcción multiplataforma con BuildKit.

  • docker-compose-plugin (5.5.1): el orquestador declarativo que invocas como docker compose.

APT añade docker-ce-rootless-extras y pigz, que docker-ce recomienda, y retira el docker-cli de Debian si venías de docker.io. El paquete deja habilitadas las unidades docker.service, docker.socket y containerd.service, y systemd arranca el servicio. Compruébalo con sudo systemctl status docker.

Para fijar una versión, lista las disponibles con apt list --all-versions docker-ce y pasa la cadena completa, como 5:29.8.1-1~debian.13~trixie, a docker-ce= y a docker-ce-cli= en el mismo apt install.

Qué cambia con Docker Engine 29 en Debian 13

Docker Engine 29.0.0, publicado el 10 de noviembre de 2025, trajo dos cambios que notas en un servidor nuevo. Las notas de la versión 29[8] los describen así:

  • El almacén de imágenes de containerd es el predeterminado en instalaciones nuevas: las imágenes van a /var/lib/containerd y los volúmenes siguen en /var/lib/docker. En la prueba, docker info mostraba driver-type: io.containerd.snapshotter.v1.

  • Hay un backend de nftables para el cortafuegos, todavía experimental, que activas con la opción firewall-backend. Sin ella, docker info mostraba Firewall Backend: iptables.

El iptables de Debian 13 es la variante sobre nf_tables (iptables v1.8.11 (nf_tables) en la prueba), y docker-ce depende de los paquetes iptables y nftables. La guía oficial avisa de que Docker solo es compatible con iptables-nft e iptables-legacy, y no admite reglas creadas directamente con nft. Crea las tuyas con iptables en la cadena DOCKER-USER.

Verificación y grupo docker

Tres comandos confirman que todo está en su sitio. Los dos primeros solo consultan el cliente; el tercero lleva sudo porque tu usuario aún no está en el grupo docker:

docker --version
docker compose version
sudo docker run hello-world

En la prueba sobre Debian 13, los dos primeros respondieron así:

Docker version 29.8.1, build 4a63305
Docker Compose version v5.5.1

El tercero descargó la imagen y, tras las líneas de progreso, imprimió:

Hello from Docker!
This message shows that your installation appears to be working correctly.

Si el último falla pero los dos primeros funcionan, revisa antes sudo systemctl status docker, porque esos dos no necesitan el daemon. Con el daemon activo, el problema suele estar en DNS o en el registry, no en la instalación.

Añadir tu usuario al grupo docker parece cosmético pero tiene implicaciones de seguridad serias, algo que el propio wiki de Debian[1] resume diciendo que pertenecer al grupo es más peligroso que tener acceso a sudo. Pertenecer al grupo equivale prácticamente a tener root en la máquina: quien puede ejecutar docker run puede montar el sistema de ficheros raíz dentro de un contenedor privilegiado. En servidor compartido, evalúa Docker rootless[9]. En servidor personal, el grupo es aceptable si conoces el compromiso.

sudo usermod -aG docker $USER
newgrp docker

newgrp aplica el grupo solo al terminal actual; para el resto, los pasos posteriores a la instalación[10] indican cerrar la sesión y volver a entrar.

Configuración que evita sorpresas

El fichero /etc/docker/daemon.json no existe tras la instalación: en la prueba, /etc/docker estaba vacío. Sin él, el driver json-file no rota nada, porque su opción max-size[11] vale -1 (sin límite). Dejarlo así es el primer error de producción que conviene evitar. Crea el fichero con los dos parámetros que merecen estar desde el primer día:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "live-restore": true
}

Sin rotación de logs, un contenedor locuaz llena el disco: el ejemplo anterior limita cada fichero a 10 MB y conserva un máximo de 3 en rotación. Con live-restore[12], los contenedores siguen en marcha mientras el daemon está parado. Docker solo lo garantiza al instalar versiones de parche (de 29.8.0 a 29.8.1), no en saltos como de 29.8 a 29.9.

Aplica los cambios con sudo systemctl restart docker, no con reload. La recarga envía SIGHUP, y la referencia de dockerd[13] solo recarga así una lista corta de opciones que incluye live-restore pero no log-opts. En la prueba, tras cambiar max-size y enviar SIGHUP, un contenedor nuevo seguía recibiendo el valor anterior. Además, la configuración de logs solo afecta a los contenedores creados después del reinicio.

Logotipo de Prometheus, herramienta de métricas que puedes usar para monitorizar el estado del daemon Docker en producción

Problemas que aparecen siempre

  • permission denied while trying to connect to the docker API: el cambio de grupo no se aplicó a la sesión. newgrp docker lo resuelve.

  • failed to connect to the docker API at unix:///var/run/docker.sock: dockerd no está en marcha. systemctl status docker y journalctl -u docker -n 100 revelan la causa.

  • Pulls lentos o rechazados: Docker Hub limita las descargas anónimas[14] a 100 cada 6 horas por dirección IPv4 o subred IPv6 /64, o hay problemas de DNS. docker login con una cuenta Personal sube el límite a 200, y un registry-mirrors local reduce las descargas.

  • Disco lleno: docker system prune -a --volumes libera espacio agresivamente, incluyendo volúmenes anónimos: ten cuidado.

Cómo hemos probado esta guía

Repetimos los pasos el 16 de septiembre de 2026 en contenedores privilegiados debian:trixie (13.6) y debian:bookworm (12.15) sobre arm64. En Debian 13 el bloque de desinstalación retiró un docker.io 26.1.5 instalado antes, y con dockerd arrancado a mano funcionaron hello-world, el grupo docker, la rotación de logs y live-restore. Sin systemd no hemos probado el arranque automático, systemctl ni journalctl, y /var/lib/containerd quedó vacío, así que esa ruta sale de la documentación. Tampoco hemos probado amd64, el kernel 6.12 de Debian, ufw ni el modo rootless.

Checklist post-instalación: de «hello-world» a servidor

El mensaje de docker run hello-world confirma que el demonio arranca. No confirma nada de lo que importa cuando la máquina deja de ser un experimento. Este es el repaso completo antes de exponer nada.

  1. Estás usando el repositorio oficial, no docker.io. Compruébalo con docker version: el repositorio instala la rama 29, y el docker.io de Debian 13 se queda en la 26.1.5.

  2. Los cinco paquetes están: docker-ce, docker-ce-cli, containerd.io, docker-buildx-plugin y docker-compose-plugin. Sin el último, docker compose (sin guion) no existe.

  3. Has decidido conscientemente sobre el grupo docker. Pertenecer a él equivale a root en la máquina. En un servidor compartido eso es una decisión de seguridad, no de comodidad: valora Docker rootless.

  4. La rotación de logs está configurada en daemon.json y has reiniciado el servicio después. Sin ella, un contenedor hablador llena el disco y se lleva por delante todo lo demás.

  5. live-restore activado si te importa que los contenedores sobrevivan a un reinicio del demonio.

  6. El servicio arranca solo: systemctl is-enabled docker. Un servidor que no se recupera de un reinicio no está en producción, está de prueba.

  7. Sabes dónde vive el estado. Los volúmenes están en /var/lib/docker/volumes, y con Docker 29 las imágenes están en /var/lib/containerd. Los volúmenes entran en tu política de backup, o no tienes backup.

  8. Has publicado el puerto a propósito. Según la guía oficial, los puertos que publica Docker se saltan las reglas de ufw y firewalld, aunque tu cortafuegos parezca cerrado. Compruébalo desde fuera de la máquina, no desde ella.

Los puntos 4 y 8 no dan síntomas el día que instalas, y por eso convierten una instalación correcta en una incidencia semanas después.

Conclusión

Lo que separa una instalación viable de una que morderá en seis meses no son los comandos del repositorio oficial, sino las decisiones que tomas justo después.

Configura la rotación de logs desde el primer día. Activa live-restore. Entiende qué implica el grupo docker. Ninguna de estas cosas aparece en los tutoriales de cinco minutos, y todas importan más que el orden exacto de los paquetes.

Con el daemon funcionando, el siguiente paso natural suele ser una interfaz de gestión: cómo instalar Portainer con Docker Compose v2. Si el plan es usar el servidor con Docker Swarm, el paso siguiente es cuándo Docker Swarm sigue teniendo sentido.

Lee también la versión en inglés: How to Install Docker on Debian 13 Step by Step.

Preguntas frecuentes

¿Necesito desinstalar docker.io antes de instalar Docker CE en Debian 13?

Sí. Ejecuta el bloque de desinstalación de esta guía antes de añadir el repositorio oficial. docker-ce declara un conflicto con docker.io, y containerd.io lo declara con containerd y runc, así que APT no deja que convivan.

¿Por qué pertenecer al grupo docker es un riesgo de seguridad?

Porque cualquier cuenta con acceso al socket de Docker puede montar el sistema de ficheros raíz dentro de un contenedor privilegiado, lo que equivale a tener root en la máquina. En un servidor compartido, la alternativa razonable es Docker rootless.

¿Qué hago si docker run hello-world falla tras la instalación?

Si docker --version y docker compose version responden pero el hello-world falla, comprueba primero con sudo systemctl status docker que el daemon está activo, porque esos dos comandos no lo necesitan. Con el daemon en marcha, el problema casi siempre es de red (DNS, acceso al registry o el límite de descargas anónimas de Docker Hub), no de la instalación.

¿Funciona esta guía en Debian 12?

Sí. Docker admite Debian 12 «Bookworm» como oldstable, y en un contenedor debian:bookworm (12.15) estos mismos comandos instalaron docker-ce 5:29.8.1-1~debian.12~bookworm, porque leen el nombre en clave de /etc/os-release. Lo que cambia es el calendario: Debian 12 terminó su soporte completo el 11 de julio de 2026. Desde entonces solo recibe soporte a largo plazo (LTS) hasta el 30 de junio de 2028, en i386, amd64, armhf, arm64 y ppc64el, y su docker.io se queda en la 20.10.24.

Fuentes

  1. wiki de Debian sobre Docker
  2. versión 26.1.5
  3. revisión del 13 de agosto de 2026
  4. directorio de paquetes
  5. guía oficial de instalación para Debian
  6. página oficial de la versión
  7. notas de publicación de Debian 13
  8. notas de la versión 29
  9. Docker rootless
  10. pasos posteriores a la instalación
  11. opción max-size
  12. live-restore
  13. referencia de dockerd
  14. limita las descargas anónimas
  15. Debian.org: información de la versión «Bookworm»