Un solo VPS, muchas apps: apuntes de cómo hospedo mi stack de IA

Cada app que lanzo pide su propio dominio, su propio certificado TLS y su propio runtime. La respuesta automática es una plataforma administrada por cada app, y funciona, justo hasta que las facturas se te acumulan y caes en cuenta de que estás pagando una suscripción mensual con tal de no aprenderte dos archivos de configuración. Esta es la apuesta contraria: un VPS, un contenedor Docker por app, Traefik al frente y visibilidad total de la máquina. Para cuando termines vas a tener el mismo armado que corro para ilustrari.com y algunas herramientas internas, la postura de seguridad que lo sostiene, y el punto honesto donde esto deja de ser la decisión correcta.

No te voy a vender una proporción mágica de apps por dólar. Te voy a mostrar cómo se conecta todo, decirte cuáles dos flags hacen casi todo el trabajo, y decirte dónde se rompe. Si vienes de ops o de seguridad, esto se va a sentir como volver a casa. Si vienes de plataformas, es la forma más barata que conozco de entender de verdad tu propia infraestructura.

01 · Por qué una sola máquina en vez de una plataforma por app

Un dev en solitario no tiene un problema de tráfico. Tienes un problema de costo y atención. Las plataformas administradas te resuelven un problema de escalado que todavía no tienes, y te lo cobran cada mes por el lujo. Un solo VPS con unos cuantos gigas de RAM corre más contenedores de los que crees, y todo está a una sesión de SSH de distancia, sin dashboard, sin página de precios por servicio, sin ese plan de "habla con ventas" que te esconde justo la perilla que necesitas.

La concesión es honesta y la quiero poner sobre la mesa desde temprano: la máquina es tuya. Los parches, los backups y el firewall ahora corren por tu cuenta. Yo lo veo como una ventaja, no como un impuesto. Vengo de liderazgo de IT, seguridad e ingeniería de telemática, así que prefiero ver toda la superficie de ataque a confiar en que un panel de control me la esconda. Superficie escondida sigue siendo superficie.

El modelo mental es chiquito a propósito. El VPS hace exactamente dos cosas:

1. Corre un solo reverse proxy que es dueño de los puertos 80 y 443 y termina el TLS de todo.
2. Corre un contenedor por app, y ninguno expone un puerto público directamente.

El proxy es lo único con lo que el internet llega a hablar. Todo lo demás vive en una red privada de Docker y, desde afuera, no se ve. Esa sola frase es toda la historia de seguridad, y el resto de esta nota es solo volverla cierta y mantenerla cierta.

02 · Traefik como puerta de entrada

Traefik es el reverse proxy. Lo elegí sobre nginx por una razón concreta: Traefik lee su enrutamiento desde labels de Docker. No editas un archivo de config central ni lo recargas cada vez que sumas una app. Levantas la app, le pones labels al contenedor, y Traefik se entera solo. Para un operador en solitario esa diferencia suma, cada deploy es un archivo menos que mantener sincronizado.

Este es el proxy en sí, como servicio de Compose:

services:
  traefik:
    image: traefik:v3.1
    restart: unless-stopped
    command:
      - --providers.docker=true
      - --providers.docker.exposedbydefault=false
      - --entrypoints.web.address=:80
      - --entrypoints.websecure.address=:443
      - --entrypoints.web.http.redirections.entrypoint.to=websecure
      - --entrypoints.web.http.redirections.entrypoint.scheme=https
      - --certificatesresolvers.le.acme.tlschallenge=true
      - --certificatesresolvers.le.acme.email=tu@correo.com
      - --certificatesresolvers.le.acme.storage=/letsencrypt/acme.json
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt
    networks:
      - edge

networks:
  edge:
    external: true

Las dos líneas que cargan todo el peso

Casi todo este archivo es boilerplate. Dos ajustes son lo único que importa.

• exposedbydefault=false, ningún contenedor recibe una ruta pública a menos que yo lo habilite a propósito con un label. Esa postura de negar por defecto es la razón entera por la que confío en este diseño. Un contenedor nuevo que levanto para un experimento rápido no se puede alcanzar desde el internet hasta que yo decida lo contrario. El default es "apagado", y "apagado" es el único default seguro.
• El resolver acme que llamé le maneja los certificados de Let's Encrypt con el challenge de TLS. El HTTPS es automático, las renovaciones pasan solas, y nunca en mi vida he entrado por SSH a rotar un cert. Ese es justo el tipo de trabajo repetitivo que quiero que haga una máquina, no yo.

El permiso del socket de Docker

Fíjate que el socket se monta en solo lectura, con el sufijo «:ro». Traefik necesita observar los eventos de los contenedores para enterarse de las rutas nuevas; no necesita controlar el daemon. El socket de Docker equivale a root en el host. Quien pueda escribir en él se adueña de la máquina. Por eso mantengo ese permiso tan estrecho como el proxy lo aguante.

03 · Un contenedor por app

Ahora una app de verdad. Así se ve el propio sitio de ilustrari.com, un solo contenedor de Next.js:

services:
  web:
    image: ghcr.io/ilustrari/site:latest
    restart: unless-stopped
    expose:
      - "3000"
    environment:
      - NODE_ENV=production
    deploy:
      resources:
        limits:
          memory: 512M
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:3000/api/health"]
      interval: 10s
      timeout: 3s
      retries: 3
    labels:
      - traefik.enable=true
      - traefik.http.routers.site.rule=Host(`ilustrari.com`)
      - traefik.http.routers.site.entrypoints=websecure
      - traefik.http.routers.site.tls.certresolver=le
      - traefik.http.services.site.loadbalancer.server.port=3000
    networks:
      - edge

networks:
  edge:
    external: true

La palabra más importante aquí es expose, no ports. La app escucha en el 3000 dentro de la red compartida edge, y solo Traefik la alcanza. No hay forma de llegar desde el internet público al puerto 3000 que no sea pasando por el proxy, que es donde viven la terminación de TLS y el enrutamiento. Si escribes ports: "3000:3000" por costumbre, acabas de abrir un hueco que se salta tu propia puerta de entrada. No lo hagas.

Sumar un proyecto nuevo es mecánico. Digamos que quiero un build de staging de Agent Orchestra, mi herramienta visual de orquestación multi-agente, al lado del sitio en producción. Son los mismos cuatro labels de router con otra regla de host:

labels:
  - traefik.enable=true
  - traefik.http.routers.orch.rule=Host(`staging.ilustrari.com`)
  - traefik.http.routers.orch.entrypoints=websecure
  - traefik.http.routers.orch.tls.certresolver=le
  - traefik.http.services.orch.loadbalancer.server.port=8080

Lo levantas, y el proxy lo agarra en segundos, cert de TLS nuevo incluido. Sin tocar ningún archivo central, sin recargar nada.

A dónde va el estado (y por qué va fuera de la máquina)

Las apps que necesitan base de datos se apoyan en Supabase, que vive totalmente fuera del VPS. Eso es una decisión deliberada, no un accidente. Mantener el estado persistente fuera de la máquina deja al VPS casi sin estado: perder la máquina es volver a desplegar, no restaurar de un backup a las 2 de la mañana. El estado es justo lo que más te conviene tener lejos de un único punto de falla. Infuse, mi bóveda de secretos de API, sigue el mismo instinto. La máquina corre la app, y los secretos que importan viven en algo hecho para cuidarlos.

04 · Redeploys que apenas tumban un request

El cero downtime de verdad necesita una orquestación que a propósito no corro aquí. Eso es otro nivel y otra factura. Pero puedes acercarte lo suficiente como para que ningún humano lo note. El truco es una sola regla: nunca borres el contenedor viejo antes de que el nuevo esté sano.

docker pull ghcr.io/ilustrari/site:latest
docker compose up -d --no-deps --wait web

El flag --wait se queda esperando hasta que el contenedor se reporte sano, lo que solo sirve de algo si definiste un healthcheck, así que defínelo (ahí está, en el snippet de Compose de arriba). Esta es la secuencia que te da el cambio casi sin costuras:

1. Compose levanta el contenedor nuevo al lado del viejo.
2. Traefik ve al nuevo unirse a la red edge y empieza a mandarle tráfico.
3. El healthcheck pasa; --wait retorna; Compose reemplaza al contenedor viejo.
4. Por un solapamiento breve los dos están vivos. Los requests en vuelo del viejo terminan, los nuevos caen en el nuevo.

Es "cero downtime más o menos", y para una operación de una sola persona ese es justo el nivel correcto. Prefiero un 99.9% honesto que entiendo por completo a una promesa frágil de 100% que no puedo explicar a las 3 de la mañana.

Para las piezas con base de datos hay una disciplina que no te puedes saltar: corre las migraciones como un paso aparte antes del deploy, y mantenlas compatibles hacia atrás por un release. Durante el solapamiento, el contenedor viejo sigue hablándole a la base de datos. Si tu migración borró una columna que él necesita, acabas de romper justo los requests que estabas tratando de proteger. Expande el esquema, despliega el código nuevo, y contrae en un release posterior. Es el clásico baile de expandir y contraer; el VPS único solo lo hace barato de practicar.

05 · La postura de seguridad que no te puedes saltar

La máquina es tuya, así que su seguridad es tuya. Esta no es una sección opcional. Es la renta que pagas por la economía. Lo innegociable, en orden de prioridad:

• Solo llaves SSH, nada de contraseñas. Deshabilita la autenticación por contraseña por completo. Los bots encuentran tu IP a las pocas horas de levantar el servidor; la auth por contraseña es una invitación abierta al fuerza bruta.
• Un firewall bien cerrado. Permite el 80, el 443 y tu puerto de SSH. Niega todo lo demás de entrada. Tus contenedores de app no necesitan puertos públicos, ese es el punto entero de la sección 03, así que el firewall y la disciplina del «expose» se refuerzan mutuamente.
• Updates de seguridad desatendidos. Parchea el kernel y el daemon automáticamente. Un fundador en solitario no va a entrar cada semana a correr updates a mano, así que pon a la máquina a hacerlo.
• fail2ban en SSH para cortar el ruido, y límites de recursos por contenedor (el límite de memory del Compose de arriba) para que un proceso desbocado no pueda ahogar a los demás.

Nada de esto es exótico. Es lo mínimo, la higiene aburrida y de toda la vida que la plataforma administrada hacía por ti calladita y te cobraba dentro de la suscripción. Ser dueño de la máquina significa ser dueño también de las partes aburridas.

06 · Dónde deja de ser buena idea

No voy a fingir que esto escala para siempre, porque fingir es justo lo que hace que te agarren desprevenido. Sé honesto sobre el techo:

• Es una sola máquina. Si el VPS muere, todas las apps se caen hasta que la reconstruyas. La mitigación es todo lo de arriba, imágenes en un registry, config en Git, para que reconstruir sea cosa de minutos, no de una tarde arruinada. Pero "minutos de downtime" sigue siendo downtime.
• No hay escalado horizontal real. Un Traefik, un host. El día que una sola app de verdad necesite varios nodos, este diseño es la herramienta equivocada y te toca buscar un orquestador en serio, ahí, no antes de tiempo.
• Los vecinos ruidosos existen. Pon límites de memoria y CPU por servicio. Un job de build que se porta mal o un experimento con fuga de memoria jamás debería poder tumbar tu sitio de marketing.
• Un SLA de cinco nueves no es esto. Si un cliente lo necesita por contrato, lo digo de frente y armamos algo distinto. Venderle a alguien un diseño de un solo VPS bajo una promesa de cinco nueves no es honestidad anti-hype. Es mala praxis.

Ahora, para lanzar productos reales como fundador en solitario, la economía es genuinamente difícil de superar: una máquina, una factura predecible y visibilidad completa de cada capa. Sé exactamente qué está corriendo, por qué y cuánto cuesta.

Hospedar lo tuyo no es un paso hacia atrás. Es elegir entender tu propia infraestructura en lugar de pagar para que otro la entienda por ti. Docker te da aislamiento, Traefik te da una puerta inteligente con TLS gratis, y Git más un registry hacen que todo sea reproducible. Empieza por el proxy, suma una app, y luego la siguiente con cuatro labels; el día que de verdad un solo VPS se te quede corto lo vas a saber, y te vas a mover con los ojos bien abiertos.