Autoaloja todo tu stack en un solo VPS

La mayoría de los proyectos pequeños recurren a una plataforma gestionada por cada servicio, una para la app, otra para la base de datos, otra para la cola, y acaban pagando precios de plataforma y juntando tres dashboards antes de tener un solo usuario. Casi nunca te hace falta nada de eso. Un solo VPS corriendo Docker Compose detrás de un reverse proxy Traefik te aloja varias apps con HTTPS automático, rutea cada una a su propio subdominio y renueva los certificados sin que tengas que pensar en ello. Esta guía te da el montaje completo de punta a punta: el endurecimiento del host, que va primero; la estructura de Compose más Traefik; un ejemplo real de cómo sumar una app de verdad; y los hábitos operativos, los backups por encima de todo, que deciden si esto es un montaje tranquilo o un incidente a las 2 de la mañana. Así es como Ilustrari corre su propio stack hoy.

01 · Prerrequisitos: blinda el host antes que nada

No te brinques esta sección para llegar a la parte divertida. A un VPS con IP pública lo empiezan a sondear a los pocos minutos de arrancar, y la diferencia entre "todo bien" y "comprometido" es la media hora que le metes al principio.

Necesitas:

• Un VPS con al menos 2 vCPU y 4 GB de RAM para correr cómodo un proxy más unos cuantos contenedores de app y una base de datos pequeña. Con 2 GB te alcanza para un par de servicios livianos. Por debajo de eso te toca pelear con el OOM killer.
• Un dominio con DNS que controles tú, para apuntar subdominios a la máquina.
• Acceso SSH por llave. Nunca auth por contraseña en un host público.

El checklist del primer login, en orden:

1. Crea un usuario no-root y dale sudo. Trabaja con ese usuario, y deja root para cuando de verdad haga falta.
2. SSH solo con llave. Sube tu llave pública y luego, en la config del demonio SSH, pon PasswordAuthentication no y PermitRootLogin no, y recarga SSH. Confirma que todavía puedes entrar desde una segunda terminal antes de cerrar la primera. Dejarte por fuera de tu propia máquina es el error clásico que uno mismo se provoca.
3. Un firewall que por defecto niega todo. Deja pasar solo la entrada por 22 (SSH), 80 y 443. Todo lo demás, incluido el puerto de tu base de datos, queda cerrado al mundo y se alcanza solo por la red de Docker o un túnel SSH.
4. Actualizaciones de seguridad automáticas del sistema, para que no seas tú la razón de que un CVE viejo siga abierto.
5. Instala Docker y el plugin de Compose desde el repo oficial de Docker, no del paquete viejo de la distro. Mete tu usuario al grupo docker para no tener que usar sudo en cada comando.

02 · La estructura: Compose define los servicios, Traefik los pone al frente

La arquitectura son tres capas, y vale la pena tenerla clara en la cabeza antes de escribir una sola línea de YAML.

• Docker Compose es tu fuente de verdad. Cada servicio, cada app, la base de datos, el propio proxy, es un bloque en un archivo Compose con una imagen fijada, un volumen con nombre para todo lo que tenga que sobrevivir a un reinicio y un lugar en una red de Docker compartida.
• Traefik es el único punto de entrada público. Escucha en 80 y 443, vigila el socket de Docker y descubre los servicios solo a partir de sus labels. Nunca editas a mano un archivo de rutas. Describes el ruteo en el contenedor al que le toca.
• Una red compartida deja que Traefik alcance cada app por su nombre de servicio, mientras que las apps en sí no quedan publicadas al host. Solo Traefik abre puertos públicos.

El modelo mental que hace que todo encaje: Traefik se configura solo a partir de los labels. Sumar una app es cuestión de ponerle labels, no de editar el proxy. Esa es justamente la razón por la que esto se mantiene manejable cuando sumas el tercer, cuarto y quinto servicio.

Dos tipos de configuración

Traefik separa la config en estática (se define una sola vez al arrancar, como entrypoints, el resolver de certificados, qué providers vigilar) y dinámica (se descubre de forma continua, como tus routers y services, leídos de los labels de los contenedores). Confundir las dos es el tropiezo más común con Traefik: un ajuste que va en la config estática no hace nada, sin avisar, cuando lo metes en un label, y al revés.

03 · Levanta Traefik con TLS automático

Aquí va el servicio del proxy. La config estática la dejo en flags de línea de comandos para que se vea todo de una vez. Más adelante puedes moverla a un archivo. Las piezas clave son los dos entrypoints, la redirección de HTTP a HTTPS y el resolver de Let's Encrypt que guarda los certificados en un volumen montado.

services:
  traefik:
    image: traefik:v3.3
    restart: unless-stopped
    command:
      - --providers.docker=true
      - --providers.docker.exposedbydefault=false
      - --entrypoints.web.address=:80
      - --entrypoints.websecure.address=:443
      # Forzar HTTP hacia HTTPS en cada router
      - --entrypoints.web.http.redirections.entrypoint.to=websecure
      - --entrypoints.web.http.redirections.entrypoint.scheme=https
      # Let's Encrypt vía challenge HTTP-01
      - --certificatesresolvers.le.acme.httpchallenge=true
      - --certificatesresolvers.le.acme.httpchallenge.entrypoint=web
      - --certificatesresolvers.le.acme.email=tu@example.com
      - --certificatesresolvers.le.acme.storage=/letsencrypt/acme.json
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./letsencrypt:/letsencrypt
      # Socket en solo lectura: Traefik lee los labels pero no controla Docker
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - edge

networks:
  edge:
    name: edge

Aquí van varias decisiones que quedan dentro y que vale la pena entender en vez de copiar a ciegas:

• exposedbydefault=false significa que un contenedor es invisible para Traefik hasta que lo activas con traefik.enable=true. Es el default seguro. Nunca publicas por accidente un servicio que se te quedó olvidado.
• El socket de Docker se monta en solo lectura. Traefik solo necesita leer la metadata de los contenedores. Un socket en solo lectura limita el daño si algún día vulneran a Traefik. Aun así da acceso de peso, así que trata al proxy como un componente de confianza.
• acme.json es un volumen, no un archivo que subes al repo. Guarda tus llaves privadas y tus certificados. Respáldalo, nunca lo subas y asegúrate de que tenga permisos estrictos (el storage de Let's Encrypt tiene que estar en modo 600 o Traefik se niega a usarlo).

04 · Suma una app: ruteo por label

Ahora la recompensa. Aquí va una app real, un servicio Next.js del tipo que corre Ilustrari, conectada a la misma red y expuesta a través de Traefik solo con labels. Fíjate que no publica ningún puerto al host. El único público es Traefik.

  app:
    image: ghcr.io/me/my-next-app:1.4.0
    restart: unless-stopped
    env_file: .env.app
    networks:
      - edge
    labels:
      - traefik.enable=true
      - traefik.http.routers.app.rule=Host(`app.example.com`)
      - traefik.http.routers.app.entrypoints=websecure
      - traefik.http.routers.app.tls.certresolver=le
      # Indícale a Traefik en qué puerto interno escucha la app
      - traefik.http.services.app.loadbalancer.server.port=3000

Lee los labels como si fueran una frase: activa Traefik para este contenedor; rutea los requests cuyo Host sea app.example.com hacia un router llamado app; sirve ese router en el entrypoint de HTTPS; saca su certificado del resolver le; y reenvía el tráfico al puerto 3000 dentro del contenedor. Apunta un registro A de app.example.com al VPS, corre docker compose up -d y en segundos tienes un sitio HTTPS funcionando con un certificado real.

Sumar una segunda app son esos mismos seis labels, cambiando app por un nuevo nombre de router y un nuevo hostname. Esa repetición es la gracia. No hay un archivo central que vaya creciendo, no hay merge conflicts en una config de rutas, no hay que reiniciar el proxy. Cada servicio carga su propio ruteo.

Fíjalo todo

• Fija los tags de imagen a versiones concretas, nunca latest. Una actualización sorpresa en un redeploy es justo lo que rompe en el peor momento una máquina que funcionaba. Lo que quieres es que los deploys sean aburridos y deliberados.
• Fija también la versión mayor de Traefik. v2 y v3 tienen una config bastante distinta, así que un proxy sin fijar que salta de versión mayor en un rebuild te tumba todas las rutas de un solo golpe.

05 · Secretos y las cosas que te muerden

Dos hábitos operativos separan un montaje en el que puedes dormir tranquilo de otro que va acumulando riesgo en silencio.

Mantén los secretos fuera de Compose

Nunca pongas credenciales inline en el archivo Compose. Es el archivo con más probabilidades de terminar en git. Usa un env_file por servicio (el .env.app de arriba), mantén esos archivos fuera del control de versiones con una entrada en gitignore y déjalos en modo 600 para que solo el dueño pueda leerlos. Para una máquina de un solo operador con eso basta. Si más adelante corres cargas no confiables o tienes varios admins, pasa a Docker secrets o a un vault externo en vez de archivos env.

La base de datos es donde la gente se quema

Es tentador soltar un contenedor de Postgres en el mismo stack de Compose. Para un proyecto pequeño está perfectamente bien, pero solo con un volumen con nombre y un procedimiento de restore probado. Dale a la base de datos un volumen con nombre para que sus datos sobrevivan a recrear el contenedor, y nunca expongas su puerto al host. Alcánzala por la red de Docker usando su nombre de servicio. La trampa no es correr la base de datos. Es dar por hecho que una base de datos que corre es una base de datos segura.

06 · Backups: la única parte que no se negocia

Una sola máquina es un solo punto de fallo. El host se puede caer, un disco puede fallar, una migración mala puede corromper datos, o puedes meter la pata con un comando destructivo. Los backups son lo que hace que todo eso pase de "se acabó la empresa" a "una tarde fastidiosa". Esta es la sección que la gente lee por encima y después lamenta.

Haz estas cuatro cosas:

1. Haz dump de la base de datos en un horario fijo, no solo un snapshot del volumen. Un dump lógico (pg_dump para Postgres) se puede restaurar entre versiones y pesa mucho menos que copiar el volumen crudo. Córrelo desde cron, varias veces al día si los datos lo ameritan.
2. Respalda también los volúmenes con estado y acme.json, para que un rebuild completo restaure los certificados y los archivos subidos, no solo la base de datos.
3. Saca los backups de la máquina. Un backup en el mismo disco que los datos se muere junto con los datos. Súbelos a un object storage o a otro host. Encríptalos, porque contienen todo lo sensible que tienes.
4. Prueba el restore. Este es el paso que todo el mundo se salta. Levanta el stack en una máquina desechable, restaura desde tu backup más reciente y confirma que la app de verdad arranca limpia. Un backup que nunca restauraste es una ilusión, no un backup.

Un solo VPS con Docker, Traefik y backups disciplinados va a llevar una operación pequeña mucho más lejos de lo que la gente cree. Es tranquilo, barato y enteramente tuyo, sin un panel de control por servicio al que estar pendiente. El trabajo que de verdad importa no es el YAML. Es la media hora de endurecimiento del host al principio y el simulacro de backup-restore que corres antes de confiar en él. Acierta en esos dos y lo demás es solo ponerle labels.