Infraestructura

Desplegar con Coolify en un servidor propio, sin quedar atado

Cómo desplegamos este sitio en un VPS con Coolify, Docker y Cloudflare: el CI decide qué llega a producción y nada depende de un solo proveedor.

4 min de lectura

Las plataformas de hospedaje administrado son cómodas hasta que cambian el precio, las reglas o el límite que te importa. Para este sitio quisimos lo contrario: un servidor propio, con piezas que se pueden cambiar una por una. Te contamos cómo está armado y por qué.

Las piezas

Pieza Qué hace Si mañana hay que cambiarla
VPS Corre los contenedores Cualquier proveedor con Docker
Coolify Construye y despliega los contenedores, con su proxy Traefik Es de código abierto; el sitio no depende de él para funcionar
Docker Empaqueta el sitio: la misma imagen en local, en CI y en producción Estándar
Cloudflare DNS, protección y caché delante del servidor El sitio funciona sin él; se pierde la caché
GitHub Actions Prueba cada cambio y decide si se despliega El flujo es un archivo del repositorio

La regla de fondo: todo lo que define el sitio vive en el repositorio. El Dockerfile, el servidor y sus cabeceras, las pruebas y el flujo de despliegue. Si el servidor desaparece, el sitio se reconstruye en otro.

Un servidor solo para esto

El sitio corre en un VPS dedicado, separado de cualquier proyecto personal o de pruebas. La razón no es la capacidad, es el radio de daño: un sitio que presume de seguridad no debería compartir servidor con experimentos. Si algo de eso se compromete, no arrastra al negocio.

El servidor solo acepta tráfico web que llega a través de Cloudflare, por IPv4 y por IPv6, y lo comprobamos desde fuera, no leyendo la configuración. El panel de Coolify no está expuesto a internet.

La imagen

El sitio se construye en una imagen Docker de varias etapas: en la primera se instalan las dependencias y se genera el sitio; en la final solo queda lo necesario para servirlo, con un usuario sin privilegios y un healthcheck que Coolify consulta. Con docker compose up levantamos en local exactamente lo que corre en producción, junto a un buzón de pruebas para el formulario.

El CI decide qué se despliega

El repositorio es privado y la cuenta es gratuita, así que GitHub no permite proteger la rama principal. Con el despliegue automático de Coolify, un push con pruebas en rojo llegaría a producción. Lo resolvimos así:

  1. En Coolify, el despliegue automático está apagado.
  2. Al fusionar un cambio, el CI ejecuta lint, tipos, build, pruebas unitarias, pruebas en navegador con axe y Lighthouse.
  3. Solo si todo pasa, un segundo flujo llama a la API de Coolify para desplegar ese commit exacto y, al terminar, purga la caché de Cloudflare.

Si el CI falla, no se despliega nada, y el fallo se ve. La protección de rama de pago habría resuelto lo mismo; esta solución cuesta cero y usa algo que ya teníamos.

La caché hace el trabajo pesado

El servidor está lejos de la mayoría de nuestros visitantes, y la distancia se nota en cada petición que llega hasta él. Cloudflare no guarda HTML en caché por defecto, así que añadimos una regla explícita para hacerlo y purgamos la caché en cada despliegue. Así, casi todas las visitas se resuelven en el nodo de Cloudflare más cercano. El resultado se ve en Lighthouse: el LCP en móvil ronda 1,5 segundos en la página de inicio.

Respaldos fuera del proveedor

Las bases de datos (hoy, la de la medición de visitas) se respaldan cada día en un almacenamiento compatible con S3 de otro proveedor. Un respaldo en el mismo servidor no sirve de nada si ese servidor desaparece. Y un respaldo que nunca se ha restaurado tampoco es un respaldo: probar la restauración es parte de nuestra lista antes del lanzamiento.

Lo que cuesta

Nada de esto es gratis en atención. Un servidor propio pide actualizaciones, vigilancia y, de vez en cuando, leer un registro a deshoras. A cambio, sabes exactamente qué corre, dónde y por qué, y puedes moverlo cuando quieras. Para un estudio que vende software a medida, esa transparencia también es parte del producto.

¿Quieres algo así para tu aplicación? Cuéntanos tu proyecto.

¿Tienes un proceso que podría funcionar mejor?

Cuéntanos cómo trabajas hoy. Con eso basta para una primera conversación.

Cuéntanos tu proyecto
Cuéntanos tu proyecto