Cómo ejecutar Docker en un VPS con Portainer (guía 2026)

¿Has oído hablar alguna vez de Dockerception?

Pues agárrate, que nos metemos en la madriguera del conejo.

Portainer, la interfaz web que vas a instalar sobre Docker, es en sí mismo un contenedor de Docker.

Es una herramienta que se ejecuta sobre lo mismo que gestiona. La pones en marcha con una sola línea de docker run, y lo primero que hace es colarse por un pequeño agujero del host (un archivo de socket) y pedirle al daemon de Docker que le muestre todos los contenedores de la máquina, incluido él mismo. Desde esa pestaña del navegador gestionas el resto de tus contenedores de Docker.

La interfaz que estás mirando aparece en su propia lista de contenedores.

En un VPS por el que ya pagas y con el que ya te manejas por SSH, Portainer encaja limpiamente sobre Docker sin cambiar cómo funciona nada por debajo.

Ese es su valor.

Una máquina de 4 GB puede ser un punto de partida para Docker y Portainer, pero son las aplicaciones que añadas las que determinan si esa capacidad basta. Piensa en la domótica, el almacén de fotos familiares, el asistente de IA y ese boletín que llevas tiempo amenazando con lanzar, todo en un servidor que es realmente tuyo.

Así puedes ponerlo en marcha, protegerlo y empezar a sacarle partido.

¿Qué es Portainer exactamente?

Portainer es una interfaz web que se ejecuta como contenedor de Docker y gestiona tus otros contenedores a través del socket de Docker.

En esencia, es un frontend en el navegador (una GUI para Docker) para los mismos comandos de Docker que, de otro modo, escribirías a mano, además de gestión de stacks, acceso basado en roles (si pasas a Business Edition) y un panel con el uso de CPU y memoria.

La conexión al socket es lo que hace que funcione. El enlace aparece como -v /var/run/docker.sock:/var/run/docker.sock en el comando de instalación, y esa única línea hace todo el trabajo pesado. Sin ella, Portainer es una interfaz para un host de Docker vacío. Con ella, Portainer es el mando a distancia del host de Docker.

Ten en cuenta una cosa: cualquier proceso que pueda acceder a /var/run/docker.sock puede controlar el daemon de Docker, y la documentación de seguridad de Docker es tajante: solo los usuarios de confianza deberían poder hacerlo, porque un contenedor iniciado a través del daemon puede montar todo el sistema de archivos del host y modificarlo sin restricciones. Eso es una ventaja cuando quien lo pide es Portainer, y un problema cuando es algún contenedor que levantaste la semana pasada y ya no recuerdas que le diste acceso al socket.

Trata el enlace al socket como una capacidad privilegiada y audita cualquier otro contenedor que lo pida.

¿Necesitas Portainer si ya tienes Docker?

No. Docker funciona perfectamente desde la terminal, y mucha gente ejecuta un par de contenedores durante años sin instalar nunca una interfaz encima.

Te conviene Portainer si:

• Vas a manejar más de dos o tres contenedores de Docker para distintas aplicaciones.
• Prefieres hacer clic en restart antes que volver a escribir un comando de Compose a las 11 de la noche.
• Compartes el acceso con alguien que no vive en la terminal.
• Quieres desplegar actualizaciones de stacks desde un repositorio Git sin escribir un script de despliegue.

Prescinde de Portainer si:

• Ejecutas uno o dos contenedores que rara vez cambian.
• Ya te manejas con Docker Compose y estás a gusto así.

Docker está tan extendido que esto no es una decisión marginal. En la encuesta para desarrolladores de Stack Overflow de 2025, el 71 % de los encuestados afirmó usar Docker, el resultado más alto entre las tecnologías de desarrollo e infraestructura en la nube, tras un salto de 17 puntos porcentuales respecto a 2024. El proyecto Portainer supera las 38 000 estrellas en GitHub a fecha de agosto de 2026.

Hay otras opciones. Dokploy, por ejemplo, se acerca más a un PaaS autoalojado completo y se encarga por ti de las aplicaciones, las bases de datos y el SSL. Portainer se mantiene más cerca de Docker puro: los mismos archivos de Compose, las mismas imágenes, solo que con una interfaz encima.

Si vives en tmux y ejecutas una sola aplicación, cierra esta pestaña. No te hace falta. Si ejecutas cuatro aplicaciones autoalojadas y este mes ya has buscado dos veces en Google ¿qué eran los logs de Docker?, sigue leyendo.

¿Qué tamaño de VPS necesitas para ejecutar Docker y Portainer?

Portainer no publica un mínimo de RAM. Un VPS de 4 GB puede servir para un stack pequeño, pero dimensiónalo a partir de los requisitos combinados del sistema operativo, el daemon de Docker y cada contenedor que pienses ejecutar.

La propia página de requisitos de Portainer dice sorprendentemente poco sobre la RAM: el Server se distribuye como un contenedor ligero, y las pautas de rendimiento de la documentación se refieren al almacenamiento (más sobre esto abajo). El cálculo real de la RAM depende de tus cargas de trabajo: reserva para el sistema operativo, el daemon de Docker y cada contenedor que pienses ejecutar. Reserva también disco para los logs: el controlador de logs json-file que Docker usa por defecto no rota los logs, así que los de un contenedor muy hablador pueden comerse bastante disco con el tiempo. La documentación de logging de Docker recomienda en su lugar el controlador local. Una vez instalado Docker (paso 2, más abajo), crea el directorio de configuración de Docker, establece el controlador de logs local y reinicia Docker: ejecuta sudo install -d -m 0755 /etc/docker, luego printf '%s\n' '{ "log-driver": "local" }' | sudo tee /etc/docker/daemon.json > /dev/null y después sudo systemctl restart docker. Hazlo antes de desplegar aplicaciones de larga duración: el controlador local rota los logs por defecto, y el cambio solo se aplica a los contenedores creados después.

Así se traduce eso a cargas de trabajo reales:

La hoja de cálculo es una simple suma: busca el requisito de RAM documentado de cada aplicación que pienses ejecutar, añade el sistema operativo y el daemon de Docker, y deja margen para los picos de uso. Portainer no publica un mínimo de RAM, así que son las aplicaciones, no la interfaz, las que llenan la máquina.

En DreamHost, nuestro Hosting VPS se ofrece en cuatro planes Stack según la RAM (Stack 4, 8, 16 y 32). El Stack 4, el plan de entrada (2 vCPU, 4 GB de RAM, 75 GB de SSD NVMe y acceso root completo), encaja de forma natural como host pequeño de Docker. Con facturación mensual cuesta 8,99 $/mes durante los 3 primeros meses y después se renueva automáticamente a 15,99 $/mes (a agosto de 2026; el plazo completo más impuestos se cobra al pagar). Las cifras actualizadas están siempre en la página del VPS con Docker + Portainer.

Si dudas de si el autoalojamiento merece la pena, el Stack 4 es el tamaño ideal para empezar: lo bastante grande para comprobarlo y lo bastante pequeño para no pagar por un margen que no vas a usar. Si tu hoja de cálculo se le queda grande, puedes subir de plan y tu entorno se mueve contigo. Eso sí, ahora mismo no se puede bajar a un Stack más pequeño, así que empieza en pequeño a propósito.

Una nota sobre el almacenamiento: el volumen de datos de Portainer guarda su propia base de datos y configuración, además de un clon de cualquier repositorio Git desde el que despliegues stacks; la documentación de Portainer advierte de que los repositorios grandes o múltiples pueden ocupar bastante disco. Las pautas de rendimiento de la documentación hablan de almacenamiento, no de memoria: lo que consideran ideal es un rendimiento de nivel SSD (≈3,5 MB/s, 30 000 IOPS o más, latencia de escritura inferior a 10 ms). El Stack 4 incluye 75 GB de almacenamiento NVMe SSD.

¿Cómo se instalan Docker y Portainer en un VPS?

Son siete pasos. El tiempo de descarga e instalación depende de tu VPS y de tu conexión. Los comandos de los pasos 2 a 6 están escritos para Ubuntu y puedes pegarlos en orden en un servidor limpio; el único comando que necesita un valor que solo tú conoces (tu propia dirección IP, en el paso 4) se indica en ese paso. (¿Prefieres saltarte toda la lista? La biblioteca de aplicaciones del hosting VPS de DreamHost incluye una imagen de Docker + Portainer con ambos ya configurados).

1. Elige una distribución de Linux

Esta guía usa Ubuntu 24.04 LTS. Docker Engine es compatible con Ubuntu 22.04, 24.04 y 26.04 LTS (a fecha de agosto de 2026). Ubuntu es uno de los sistemas operativos preinstalados disponibles en el hosting VPS de DreamHost.

Debian y las distribuciones de la familia RHEL, como AlmaLinux, también sirven, pero tienen sus propias rutas de instalación en la documentación de Docker y los comandos de abajo no funcionarán tal cual. Un detalle más en la familia RHEL: la documentación de instalación de Portainer da por hecho que SELinux está desactivado e indica que, si necesitas SELinux activado, pases --privileged a Docker al desplegar Portainer. Si esta frase no te ha dicho nada, usa Ubuntu.

¿No sabes qué versión de Ubuntu tienes? Descubre cinco formas de comprobarlo.

2. Instala Docker desde el repositorio oficial

No ejecutes apt install docker.io ni instales Docker mediante snap: la documentación oficial de instalación de Docker incluye docker.io entre los paquetes no oficiales que hay que desinstalar antes de instalar Docker Engine, y la documentación de instalación de Portainer advierte de que el paquete snap puede causar problemas de compatibilidad.

Primero, elimina cualquier paquete en conflicto. Este es el comando de eliminación de la documentación de instalación actual de Docker, y en un servidor limpio normalmente no encuentra nada que quitar; la documentación indica que apt puede informarte de que no tienes instalado ninguno de estos paquetes:

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

A continuación, añade la clave GPG de Docker (cada línea de abajo es un comando independiente):

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Después, añade el repositorio apt de Docker. Esto escribe la definición del repositorio en /etc/apt/sources.list.d/docker.sources (el archivo que usa la documentación de instalación de Docker) con tu versión de Ubuntu y la arquitectura de tu CPU rellenadas automáticamente:

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

Por último, instala Docker Engine y el plugin de Compose de una vez:

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

3. Comprueba que Docker está en ejecución

Ejecuta sudo docker run hello-world.

Si no aparece el mensaje Hello from Docker!, arregla el daemon antes de poner Portainer encima.

4. Integra UFW con Docker antes de iniciar Portainer

Esta es la parte que la mayoría de las guías dejan para el final, cuando ya es tarde: cuando Docker publica un puerto, el tráfico hacia él se desvía antes de llegar a las cadenas que filtra UFW, así que un puerto publicado es accesible desde internet aunque UFW diga que está denegado. (La explicación completa está más abajo). En cuanto inicies Portainer, su puerto 9443 será público, justo durante esos cinco minutos en los que quien llegue primero puede crear la cuenta de administrador. Así que arregla el cortafuegos primero.

Si UFW no está activo, permite SSH y actívalo. (Si tu SSH usa un puerto personalizado, permite ese puerto en lugar del 22, o este será el paso en el que te quedes fuera).

sudo ufw allow 22/tcp
sudo ufw enable

Después, instala chaifeng/ufw-docker, una herramienta de terceros que añade las reglas necesarias a /etc/ufw/after.rules para que el tráfico hacia los puertos publicados por Docker se filtre a través de la cadena DOCKER-USER. Los comandos de abajo fijan la versión 251123 del proyecto (noviembre de 2025) en lugar de tirar de la rama master, que cambia constantemente, y usan curl, que instalaste en el paso 2:

sudo curl -fsSL -o /usr/local/bin/ufw-docker \
  https://github.com/chaifeng/ufw-docker/raw/251123/ufw-docker
sudo chmod +x /usr/local/bin/ufw-docker
sudo ufw-docker install
sudo ufw reload

Tras la recarga, los puertos publicados de los contenedores se filtran a través de UFW. Si tu política de tráfico enrutado deniega las conexiones entrantes y ninguna regla existente permite el puerto, las conexiones públicas seguirán bloqueadas hasta que las permitas explícitamente. (El proyecto ufw-docker indica que, si las reglas no surten efecto tras reiniciar UFW, se soluciona reiniciando el servidor).

Ahora autoriza de antemano tu propio acceso a la interfaz de Portainer. Sustituye YOUR_HOME_IP por la IP pública desde la que vas a navegar:

sudo ufw route allow proto tcp from YOUR_HOME_IP to any port 9443

Con esta regla configurada antes de que arranque Portainer, el tráfico IPv4 hacia la interfaz solo se permite desde tu IP y la de nadie más, incluso durante la ventana de creación del administrador inicial. Tal como está escrita, la regla solo cubre IPv4. La documentación de ufw-docker dice que la herramienta también es compatible con redes IPv6 y que actualiza /etc/ufw/after6.rules cuando es necesario, pero no te fíes a ciegas: si tu VPS responde en una dirección IPv6 pública, ejecuta también por IPv6 la prueba desde fuera que verás en la sección del firewall antes de confiar en ella. La contrapartida: la mayoría de las conexiones domésticas cambian de IP de vez en cuando, así que puede que tengas que actualizar la regla más adelante. Si eso te molesta, la solución más limpia a largo plazo es poner una VPN delante de la interfaz (lo vemos en la sección de protección).

5. Crea un volumen persistente para los datos de Portainer

Después, ejecuta sudo docker volume create portainer_data.

Guardar la base de datos de Portainer en un volumen de Docker (y no dentro del contenedor) significa que una actualización de Portainer no borrará tu configuración.

6. Ejecuta Portainer Community Edition

Este es el comando de la documentación de instalación en Linux de Portainer, menos una opción: la versión oficial también publica el puerto 8000, un túnel TCP que solo hace falta si más adelante conectas entornos remotos mediante Edge Agents. Una instalación en un único host no lo necesita, así que lo omitimos:

sudo docker run -d \
  -p 9443:9443 \
  --name portainer \
  --restart=always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:lts

Vamos a desglosarlo línea por línea:

• -d lo ejecuta en segundo plano.
• -p 9443:9443 es la interfaz web de Portainer por HTTPS: el puerto que permitiste para tu IP en el paso 4.
• --restart=always vuelve a levantar Portainer tras un reinicio.
• Las opciones -v son el enlace al socket y el volumen persistente del paso 5.
• :lts te fija a la línea de versiones Long Term Support de Portainer, la etiqueta que usa la propia documentación de instalación de Portainer.

7. Abre la interfaz y crea tu cuenta de administrador

Abre en tu navegador https://YOUR_VPS_IP:9443 (desde la dirección IP que permitiste en el paso 4).

Acepta la advertencia del certificado autofirmado. Llegarás a la pantalla create the initial administrator user. Elige un nombre de usuario que no sea admin, establece una contraseña segura y guárdala en un sitio fiable. Y… ¡ya estás dentro!

¿Por qué Portainer ha agotado el tiempo de espera?

Porque Portainer espera exactamente cinco minutos a que alguien lo reclame en la primera instalación. Si nadie lo hace, cierra la puerta.

Textualmente, de las preguntas frecuentes de Portainer:

As a security precaution, when Portainer is first installed it will wait for 5 minutes for an administrator user to be created (part of the initial setup). If a user is not created within those 5 minutes, the Portainer Server will stop listening for requests.

Traducción: si te pasaste el paso 6 preparándote un bocadillo, tu instalación ahora se niega a hablar contigo, y no has hecho nada mal.

La solución es sencilla. Ejecuta sudo docker restart portainer.

Eso vuelve a levantar el contenedor, te da otra ventana de cinco minutos y te lleva a la pantalla de creación del administrador. Repite las veces que haga falta. Bienvenido al autoalojamiento.

Si estás automatizando la instalación para una flota de servidores (Ansible, Terraform, un pipeline de despliegue), Portainer acepta la opción --admin-password-file, que crea el usuario administrador a partir de un archivo cuando el contenedor arranca por primera vez, así que no hay ninguna pantalla de creación del administrador contra la que correr. La documentación de configuración por CLI de Portainer explica la sintaxis. Para una instalación puntual en un VPS, el truco del reinicio basta.

¿Cómo evitas que Docker se salte tu cortafuegos?

Ya lo hiciste en el paso 4. Esto es lo que pasó realmente, cómo abrir puertos a propósito y cómo comprobar que funciona.

El problema: cuando publicas el puerto de un contenedor con -p 80:80, ese puerto es accesible desde internet aunque ufw status muestre el puerto 80 como denegado. Según la documentación de filtrado de paquetes de Docker, Docker routes container traffic in the nat table, which means that packets are diverted before it reaches the INPUT and OUTPUT chains that ufw uses.

UFW no está roto. Simplemente está vigilando el pasillo equivocado.

La solución que propone el propio Docker es la cadena de iptables DOCKER-USER: una cadena que Docker crea específicamente para reglas definidas por el usuario y que se procesa antes que las reglas de las cadenas propias de Docker. El script ufw-docker que instalaste en el paso 4 conecta UFW con esa cadena añadiendo un bloque de reglas (entre los marcadores # BEGIN UFW AND DOCKER y # END UFW AND DOCKER) a /etc/ufw/after.rules, para que se cargue con el resto de tu configuración de UFW.

Para abrir a propósito un puerto de un contenedor al público (por ejemplo, una aplicación web en el puerto 80 del contenedor), usa una regla de enrutamiento:

sudo ufw route allow proto tcp from any to any port 80

Una trampa que señala la documentación de ufw-docker: la regla usa el puerto del contenedor, no el del host. Si publicaste con -p 8080:80, la regla anterior (puerto 80) es la correcta, no el puerto 8080.

Para comprobarlo desde fuera, haz la prueba desde una red que no esté en tu lista de permitidos (el punto de acceso del móvil sirve). Esto debería agotar el tiempo de espera en lugar de devolver la página de inicio de sesión de Portainer:

curl -k --max-time 5 https://YOUR_VPS_IP:9443

# For IPv6, enclose the address in square brackets:
curl -k --max-time 5 'https://[YOUR_VPS_IPV6]:9443'

Ejecuta el mismo comando desde la IP que permitiste en el paso 4 y deberías recibir HTML. Que UFW diga denied es una afirmación; un tiempo de espera agotado desde una red ajena es una prueba.

Para deshacerlo todo, ejecuta sudo ufw-docker uninstall, que según la documentación del proyecto restaura tu configuración de UFW y elimina los archivos que instaló, y después sudo ufw reload. También puedes eliminar a mano el bloque entre los marcadores # BEGIN UFW AND DOCKER y # END UFW AND DOCKER en /etc/ufw/after.rules y recargar UFW.

Esto pilla desprevenidos a ingenieros expertos tanto en servidores personales como en producción: UFW dice una cosa, internet dice otra y la verdad está en iptables. Si prefieres que Portainer no tenga ningún puerto público, ponle delante un túnel VPN como WireGuard.

¿Qué deberías proteger justo después del primer inicio de sesión?

Ya estás dentro. Cinco cosas que merece la pena hacer antes de cerrar esa pestaña del navegador (las cuatro primeras vienen directamente de la guía de seguridad de Portainer):

• Activa Force HTTPS only. La instalación de esta guía solo publica el puerto 9443, así que, de entrada, no hay ningún puerto HTTP expuesto. Activar el interruptor Force HTTPS only en Settings → SSL Certificate lo deja fijado: según la documentación de ajustes de Portainer, desactiva por completo la escucha en el puerto HTTP heredado (9000), de modo que un futuro redespliegue que añada -p 9000:9000 no pueda reabrir una vía sin cifrar.
• Sustituye el certificado autofirmado. Sube un certificado que hayas generado o pon delante de Portainer un proxy inverso NGINX con un certificado de Let’s Encrypt. Pasado el primer día, aceptar la advertencia del navegador cada vez es una costumbre de la que te arrepentirás.
• Usa un nombre de administrador de verdad. Usar el nombre de usuario predeterminado admin le ahorra a un atacante una credencial que adivinar. Elige algo propio.
• Restringe la interfaz a una VPN. Ejecutar Portainer detrás de una VPN WireGuard es el patrón que recomienda la guía de seguridad de Portainer. Un 9443 restringido a tu IP de origen (paso 4) está bien. Un 9443 al que solo se puede acceder desde una red privada es mejor.
• Audita el enlace al socket de Docker. Cualquier cosa con acceso a /var/run/docker.sock controla el daemon de Docker y, a través de él, el host. No montes el socket a la ligera en otros contenedores. Cada enlace adicional es una nueva vía hacia el host. Si un contenedor dice que necesita el socket, pregunta por qué, y plantéate usar un proxy de socket si la respuesta es para monitorización.

¿Cómo se usa Portainer en el día a día?

La recompensa de instalar Portainer llega el día en que dejas de conectarte por SSH para reiniciar un contenedor que da guerra y empiezas a pulsar un botón. La recompensa mayor es la gestión de stacks.

Un stack de Portainer es una aplicación multicontenedor definida por un archivo de Docker Compose. Portainer puede desplegar configuraciones de Docker Compose compatibles como stacks por cuatro vías que recoge la documentación oficial de stacks:

• Pega el Compose en el editor web
• Sube un archivo Compose
• Apunta Portainer a un repositorio Git
• Despliega desde una plantilla personalizada

La vía de Git es la que importa. Apuntas Portainer a un repositorio público o autenticado y a la ruta de docker-compose.yml, y activas las actualizaciones GitOps. Portainer consulta el repositorio cada cierto intervalo que tú defines o te da una URL de webhook para añadirla a tu servicio Git (que se activa desde una GitHub Action, por ejemplo). Cuando el archivo Compose cambia en origen, Portainer lo descarga y vuelve a desplegar automáticamente. Y sí, funciona en Community Edition: en la página de documentación de stacks, solo la opción de volúmenes con rutas relativas lleva la marca de Business Edition.

Es la versión autoalojada del despliegue al hacer push sin pagar a un PaaS por el privilegio.

Las pequeñas ventajas del día a día también suman: consultar los registros en un panel en lugar de seguirlos desde la línea de comandos, reiniciar con un clic, reconstruir un stack con un botón y ver gráficos de recursos que puedes revisar en tres segundos en lugar de ejecutar Docker stats.

Si más adelante añades hosts remotos mediante Edge Agents, el puerto 8000 vuelve a entrar en juego: las preguntas frecuentes de más abajo explican el redespliegue y la regla del firewall.

¿Cómo haces copias de seguridad de Portainer y tus contenedores?

Un volumen es persistencia, no una copia de seguridad. El volumen portainer_data del paso 5 sobrevive a las actualizaciones del contenedor, pero vive en el mismo disco que todo lo demás, así que un plan de copias de seguridad de verdad tiene tres partes, y las tres salen del VPS.

1. La configuración de Portainer. En la interfaz, ve a Settings → Back up Portainer, deja la opción predeterminada Download backup file y haz clic en Download backup. Según la documentación de ajustes de Portainer, eso descarga un tar.gz con todo lo que Portainer guarda en su volumen /data, opcionalmente cifrado con contraseña, y ese archivo es todo lo que necesitas para restaurar Portainer. La documentación también es clara sobre el alcance: copia solo la configuración de Portainer, no los contenedores, stacks ni volúmenes que hayas desplegado. (Existen copias programadas a S3, pero solo en Business Edition; en CE, ponte un recordatorio periódico en el calendario.)

2. Los datos de tus aplicaciones. La documentación de volúmenes de Docker considera los volúmenes con nombre la forma preferida de conservar los datos de los contenedores, y más fáciles de copiar o migrar que los montajes bind. Un montaje de solo lectura solo impide escribir al contenedor de la copia de seguridad: la propia aplicación puede seguir escribiendo en el volumen a mitad del archivado y dejarte una copia incoherente. Así que primero detén el contenedor de la aplicación (sudo docker stop myapp) o usa el mecanismo de copia de seguridad que admita la aplicación. Después monta el volumen en solo lectura en un contenedor desechable, empaquétalo con tar y vuelve a arrancar la aplicación (sustituye los nombres por los tuyos):

sudo docker run --rm \
  -v myapp_data:/source:ro \
  -v "$PWD":/backup \
  alpine tar czf /backup/myapp_data.tgz -C /source .

Para bases de datos, mejor usa la herramienta de volcado de la propia base de datos (pg_dump, mysqldump) que copiar archivos de datos en uso, para no archivar un archivo a mitad de escritura. Después envía los archivos fuera del servidor de forma programada: rsync o scp a otra máquina, o súbelos a un Object Storage. Una copia de seguridad que vive en el disco que respalda desaparece con ese disco.

3. Tus archivos Compose y secretos. Si despliegas stacks desde Git, los archivos Compose ya están fuera del servidor. Lo que Git no guarda es todo lo que nunca subiste: archivos .env, claves de API y contraseñas que introdujiste al desplegar. Los directorios montados con bind también quedan fuera de la copia de volúmenes anterior. Haz inventario de todo eso por separado y guarda una copia cifrada.

Después, prueba la restauración antes de necesitarla. La documentación de Portainer dice que la restauración de la configuración solo funciona en una instancia nueva: despliega un nuevo contenedor de Portainer con un volumen de datos vacío (un VPS desechable o tu portátil sirven), elige Restore Portainer from backup durante la configuración inicial y confirma que puedes iniciar sesión con tus credenciales antiguas y ver las definiciones de tus stacks. Ese simulacro solo cubre la parte 1: la configuración de Portainer. Las partes 2 y 3 necesitan su propia prueba, aplicación por aplicación: restaura un archivo en un volumen nuevo, arranca la aplicación con él y comprueba que los datos están realmente ahí. Una copia de seguridad sin probar es una esperanza con nombre de archivo.

¿Cuánto cuesta Portainer? (¿Y cuándo deja de ser gratis lo gratis?)

Portainer es gratis por partida doble. Community Edition es gratuita y de código abierto (licencia zlib), sin necesidad de clave de licencia. Y Portainer Business Edition es gratis para siempre hasta 3 nodos: todas las funciones de Business, sin límite de tiempo y sin tarjeta de crédito. En lugar de pagar, te registras para obtener una clave de licencia gratuita.

Precios de la página de precios de Portainer a agosto de 2026; Starter y Scale requieren un compromiso anual.

Entonces, ¿cuál eliges? Para un único VPS con un solo administrador, Community Edition: es de código abierto, no requiere registro y hace todo lo que ves en esta guía, incluidos los despliegues desde Git. Si quieres control de acceso basado en roles (RBAC) para un segundo usuario, o ya gestionas dos o tres servidores, elige el nivel gratuito de Business para 3 nodos: es el mismo software con las funciones de Business desbloqueadas, gratis mientras no pases de tres nodos. Los planes de pago solo tienen sentido cuando gestionas un número considerable de nodos en equipo. Y revisa el tipo de soporte antes de dar por hecho que pagar significa tener soporte: a fecha de agosto de 2026, la página de precios de Portainer indica soporte de la comunidad en el plan Starter, soporte 9×5 con respuesta al siguiente día laborable a partir del plan Scale y soporte prioritario en Enterprise.

¿Deberías añadir Portainer o prescindir de él?

Aquí tienes la respuesta sincera en dos frases:

✅ Si vas a compartir este servidor, desplegar desde Git o ejecutar más de tres contenedores dentro de un año, instala Portainer ahora que el servidor está recién configurado y tus hábitos aún se están formando.

❌ Si ejecutas una sola app tranquila y te sientes a gusto en la terminal, no echarás de menos la interfaz que no instalaste.

La verdadera pregunta no es Portainer sí o Portainer no, sino si el autoalojamiento es lo adecuado para ti. Y eso ya lo respondiste cuando abriste esta pestaña.

Un VPS de 4 GB, Docker y Portainer CE bastan para empezar a autoalojar en serio: elige tus apps, suma sus requisitos documentados y deja que sean los cálculos, y no la lista de deseos, los que decidan cuándo necesita crecer el servidor.

No está nada mal.

Preguntas frecuentes sobre Docker y Portainer