El peaje de la comodidad

Todo empezó con un droplet de DigitalOcean de 4 dólares al mes y una idea bastante modesta: quería alojar ahí mis diez o quince sitios estáticos —portfolio, landings, experimentos, alguna demo de cliente—, cada uno con su propio dominio, apuntando a mi propia IP. Nada exótico. Un VPS chico, unos cuantos sitios estaticos y un poco de disciplina.

Lo que descubrí es que ese camino, el más obvio de todos, está lleno de peajes.

La primera opción fue la de siempre: Netlify. Es excelente, el free tier es generoso y el DX es de otro planeta. Pero yo ya tenía el servidor, ya tenía los dominios, y Netlify me pedía lo único que no quería entregar: o cambiaba los nameservers de mis dominios para que los gestione su DNS, o me conformaba con sus subdominios. Estaba pagando un VPS para tener control y, al mismo tiempo, delegando el control a un tercero. La cuenta no cerraba conceptualmente, aunque cerrara económicamente.

La segunda opción fue Coolify, y acá quiero ser claro porque es un proyecto que admiro: Coolify es una herramienta enorme, open source, bien pensada, y para el 90% de los casos de uso es la respuesta correcta. El problema no es Coolify. El problema es lo que Coolify necesita para vivir.

Coolify es auto-alojado. Eso significa que el panel, la base de datos, el proxy, el motor de builds y la cola de trabajos corren dentro de tu servidor, compitiendo por RAM con los sitios que querés servir. La documentación recomienda arrancar con 2 GB, y en la práctica, si vas a buildear proyectos de frontend ahí adentro, querés 4. En DigitalOcean eso es un droplet de 24 dólares al mes.

Hagamos la cuenta juntos:

Veinte dólares de diferencia por mes. Doscientos cuarenta al año. Para servir archivos estáticos.

Y ahí apareció la pregunta que originó todo el proyecto, que en retrospectiva es casi vergonzosamente simple: ¿por qué el panel de control tiene que vivir en el servidor?

Un panel de deploy hace tres cosas: habla con GitHub, habla con tu servidor por SSH y te muestra una interfaz para decidir qué va a dónde. Ninguna de esas tres cosas necesita ejecutarse en producción. Son tareas de administración, y las tareas de administración se hacen desde donde estás sentado.

PushBox nace de invertir esa relación. Corre en tu notebook: un backend en Node y una UI en React. Lo abrís cuando querés configurar algo, hacés lo tuyo, y lo cerrás. El servidor, mientras tanto, no sabe que PushBox existe: lo único que corre ahí es Caddy sirviendo archivos.

Las consecuencias de esa decisión son bastante lindas:

• El VPS queda libre. Sin panel, sin base de datos de panel, sin worker de builds. Un droplet de 512 MB sirve sitios estáticos hasta aburrirse.
• No hay dashboard expuesto a internet. La superficie de ataque más obvia de cualquier PaaS auto-alojado —un login web público con permisos de root sobre tu infra— sencillamente no existe.
• No hay intermediario. Tu Personal Access Token de GitHub y tus credenciales SSH viven en una SQLite local, cifrada con AES-256-GCM, en tu máquina. No hay telemetría, no hay servicio de terceros, no hay cuenta que crear.
• Si el proyecto muere, la infra sigue viva. Y este punto es el que más me importa: PushBox configura cosas estándar y se corre a un costado. Lo que queda funcionando es un workflow de GitHub Actions y un Caddyfile. Si mañana el proyecto deja de existir, los deploys siguen andando igual.

El flujo completo son cuatro etapas, y me gusta que cada una deje atrás un artefacto que podés leer, versionar y borrar a mano.

1. Hardening del servidor (con red de contención)

Lo primero es que el VPS deje de ser un servidor recién creado con SSH abierto al mundo. PushBox se conecta por SSH y corre un asistente de endurecimiento: crea un usuario no-root con sudo, instala tu clave pública, deshabilita el login por contraseña, deshabilita el acceso directo de root, mueve el puerto de SSH si querés y levanta el firewall dejando pasar lo mínimo indispensable.

Nada de eso es original: es lo que todos hacemos a mano leyendo el mismo tutorial por decimoquinta vez.

2. Detección de stack

Después PushBox se conecta a tu cuenta de GitHub, lista tus repositorios y, cuando elegís uno, lo inspecciona para deducir con qué está hecho. Hoy reconoce Vite + React, Astro, Flutter Web y una opción Custom para todo lo demás.

Detectar el stack no es magia, es leer el package.json, el pubspec.yaml y los archivos de configuración que ya están ahí. Pero es la diferencia entre "configurá tu comando de build y tu directorio de salida" y "encontré Astro, el build es astro build y la salida va a dist/, ¿está bien?". La segunda opción no requiere que recuerdes nada. Y si se equivoca, editás el campo y listo: la detección propone, nunca impone.

3. La rama pushbox y el workflow inyectado

Acá está el corazón del asunto, y es donde PushBox se diferencia de todo lo que estaba mirando. Los builds no corren en tu servidor. Corren en GitHub Actions.

El servidor no compila nada. No tiene Node instalado, no tiene el toolchain de Flutter, no tiene una carpeta node_modules de 400 MB por proyecto. Lo único que hace es recibir archivos ya compilados y servirlos. Por eso alcanza con un droplet de 4 dólares: no le estamos pidiendo que piense, le estamos pidiendo que sirva.

El mecanismo es deliberadamente aburrido:

1. PushBox crea una rama llamada pushbox en tu repositorio.
2. Escribe ahí un .github/workflows/deploy.yml con el pipeline que corresponde a tu stack detectado.
3. Te muestra el diff y te pide confirmación explícita.
4. Mergea esa rama a main.

Desde ese momento, cada git push a main dispara el workflow: GitHub instala dependencias, buildea, y sube el resultado por rsync sobre SSH al directorio del sitio en tu VPS. Deploy automático, sin webhooks propios, sin agentes corriendo en el servidor, sin un demonio escuchando en algún puerto.

Que el artefacto sea un .yml común y corriente dentro de tu repositorio, y no una configuración encerrada en la base de datos de un panel, es una decisión de la que estoy bastante orgulloso. Es auditable, versionable y editable a mano. Y es tuyo.

4. Caddy y los certificados que nunca más mirás

La última pieza es el servidor web. PushBox instala y configura Caddy en el VPS, y le agrega un bloque por cada sitio que despliegues:

Eso es todo. Caddy resuelve el certificado TLS con Let's Encrypt automáticamente la primera vez que alguien entra al dominio, y lo renueva solo para siempre. Sin certbot, sin cron de renovación, sin el clásico mail de "tu certificado vence en 7 días" que llega justo cuando estás de vacaciones.

Elegí Caddy sobre Nginx precisamente por eso: para servir sitios estáticos con HTTPS, el bloque de configuración de Caddy tiene cinco líneas y el de Nginx tiene cuarenta, la mitad de las cuales son sobre certificados. Cuando la herramienta escribe la configuración por vos, la legibilidad de esa configuración importa el doble, porque es lo que vas a leer el día que algo falle.

Sería muy fácil terminar acá y dejar la impresión de que armé un reemplazo de Netlify en un fin de semana. No lo hice, y conviene decirlo con la misma claridad con la que conté lo bueno.

PushBox solo sirve sitios estáticos. No hay contenedores, no hay bases de datos, no hay funciones serverless, no hay backends. Si tu proyecto necesita algo de eso, Coolify es tu herramienta y lo digo sin ironía: hace bastante más que esto, y por eso pide bastante más servidor.

Tampoco es multi-usuario: corre en tu máquina, para vos. No tiene panel de métricas ni logs centralizados —para eso están los logs de Caddy y la pestaña de Actions—. Y por ahora asume un VPS Debian o Ubuntu con acceso SSH, Node 24+ y pnpm 11 en tu máquina, más un Personal Access Token de GitHub.

Es una herramienta chica que hace una cosa. Esa fue exactamente la intención.

PushBox salió de un fin de semana de fastidio y de una cuenta muy simple: 240 dólares al año es demasiado para servir HTML. Hoy despliega todos mis sitios, incluido el que estás leyendo, sobre el mismo droplet de 4 dólares que lo originó, y el servidor está tan vacío que casi da risa.

El código está abierto bajo licencia MIT en github.com/KazmerMaximiliano/PushBox. Se arranca así:

git clone https://github.com/KazmerMaximiliano/PushBox
cd PushBox
pnpm install
pnpm dev

Si tenés un VPS abandonado juntando polvo y unos dominios propios, probalo y contame cómo te fue. Si te resulta útil, una ⭐ en el repositorio ayuda más de lo que parece a que otra gente con el mismo problema lo encuentre. Y si te faltó un stack —Next en export estático, SvelteKit, Hugo, lo que uses—, el detector de frameworks está pensado para ser extendido con un archivo por stack: los issues y los PRs están abiertos, y ese es probablemente el mejor lugar para una primera contribución.

Es un proyecto de fin de semana. No pretende competir con nadie. Solo quería que mi droplet de 4 dólares hiciera exactamente lo que le pedí, sin intermediarios y sin peajes.