/dev/push: un «push to deploy» open source para autoalojar despliegues tipo Vercel... pero en tu propio servidor

Durante años, plataformas como Vercel o Netlify han acostumbrado a muchos equipos a una idea muy potente: hacer push a Git y ver tu app desplegada en minutos, con cambios sin cortes, logs accesibles y entornos bien separados. El problema es que esa comodidad suele venir con peajes: costes que crecen cuando el proyecto despega, límites de personalización y, en algunos casos, un ?lock-in? que complica salir cuando tu infraestructura madura.

En ese hueco entra /dev/push (también referenciado como devpush), un proyecto open source y autoalojable que busca ofrecer una experiencia muy parecida a ?push to deploy?, pero corriendo en tus propios servidores. Su propuesta es clara: despliegues desde GitHub con actualizaciones zero-downtime, rollback rápido, logs en tiempo real y gestión básica de equipos, sin obligarte a montar un Kubernetes completo para tener algo ?decente?.

Qué es exactamente /dev/push

La definición del proyecto no se anda con rodeos: una alternativa open source y self-hosted a servicios tipo Vercel/Render/Netlify, capaz de desplegar apps (Python, Node.js, PHP? y, en general, cualquier cosa que pueda ejecutarse en Docker) directamente desde GitHub, con rollouts sin caída y posibilidad de volver atrás casi al instante.

A nivel de producto, apunta a ese punto medio interesante: más simple que una plataforma PaaS ?de verdad? y bastante más amable que un conjunto de scripts caseros. Si tu caso de uso es ?quiero desplegar rápido, con control y dominios propios?, entra bien.

Cómo funciona por debajo

Aquí está lo relevante para cualquier perfil dev:

• El motor real es Docker. /dev/push organiza la configuración de cada proyecto (repo, imagen, comandos de build y arranque, variables de entorno, etc.).
• Cuando llega un evento (webhook) desde GitHub, el sistema clona, construye y levanta el nuevo contenedor, y si todo va bien, intercambia la versión anterior por la nueva, buscando que el cambio sea transparente.
• El enfoque está pensado para trabajar con entornos (por ejemplo, staging/producción) y para mantener una operativa de despliegue repetible, sin reinventar una pipeline distinta por app.

Traducido al lenguaje de ?equipo pequeño con varios servicios?: te quitas gran parte del pegamento (webhooks, builds, arranque, routing, certificados y operación diaria) sin renunciar a controlar el servidor.

Funciones clave que importan a un equipo de desarrollo

Entre las capacidades más útiles para el día a día destacan:

• Despliegues desde GitHub y enfoque Git-first.
• Actualizaciones sin downtime y rollback rápido.
• Logs de build y ejecución en tiempo real, con búsqueda.
• Gestión de entornos y variables (incluyendo variables cifradas, según el enfoque descrito en la doc).
• Equipos y permisos (RBAC) para no compartir una única cuenta entre todos.
• Dominios propios y certificados SSL automáticos con Let?s Encrypt.
• Licencia MIT y filosofía ?lo ejecutas donde quieras?.

La combinación de ?dominios + SSL + despliegue por push? es lo que suele convertir una idea en herramienta de trabajo real: puedes mover staging/producción a un servidor tuyo y dejar de tratar cada despliegue como una operación manual.

Instalación: requisitos y pasos típicos

/dev/push se posiciona como una instalación razonable en un servidor Linux estándar. En la documentación oficial se indica soporte (al menos oficial) para Ubuntu 20.04+ o Debian 11+, recomendando 4 GB o más de RAM, acceso por SSH y permisos de sudo.

Además, la guía lista dependencias prácticas:

• DNS (recomiendan Cloudflare).
• Una cuenta de GitHub (hay que crear una GitHub App para login y acceso a repos).
• Un proveedor de email (mencionan Resend) para correos de acceso e invitaciones.

El ?quick install? que proponen es directo:

curl -fsSL https://install.devpu.sh | sudo bash

Tras eso, el flujo habitual pasa por editar el .env (en la ruta indicada por la documentación) con credenciales y dominios, configurar DNS (incluyendo un wildcard para despliegues) y levantar el servicio.

Ojo con SSL y Cloudflare: detalles que evitan sustos

La guía entra en matices importantes si usas Cloudflare:

• Recomiendan el modo ?Full (strict)? en SSL/TLS.
• Explican la diferencia práctica entre HTTP-01 y DNS-01 (este último suele ser más cómodo para wildcards o si quieres evitar depender del puerto 80).
• También recuerdan una limitación típica: el Universal SSL gratuito cubre wildcards de primer nivel (tipo *.example.com), pero no sub-subdominios (*.sub.example.com).

Esto no es ?relleno?: es justo lo que suele romper instalaciones en la primera hora y provocar el clásico bucle de ?¿por qué Let?s Encrypt falla??.

Operación y mantenimiento: actualizar y volver atrás

Uno de los puntos que más separa un proyecto serio de un ?script bonito? es qué pasa cuando actualizas.

La documentación describe un script de actualización que automatiza la rutina típica: backup, pull del código, hooks de upgrade, rebuild de contenedores y reinicio del servicio.

También contemplan actualización manual y, lo más importante, rollback restaurando desde el backup previo si algo sale mal.

Y para quien quiera ver la ?caja de herramientas?, /dev/push enumera scripts para backups, restore, build de runners, limpieza, logs, etc., lo que da pistas de cómo han pensado la operativa del proyecto.

¿Para quién encaja (y para quién no)?

Encaja bien si:

• Quieres una experiencia tipo PaaS ?ligera? para varios proyectos sin montar una plataforma enorme.
• Trabajas con microservicios sencillos, webapps, APIs, backoffice y necesitas staging/producción con dominios y certificados.
• Te interesa el control: hosting propio, costes predecibles, datos bajo tu gestión.

Puede no encajar si:

• Necesitas orquestación avanzada, autoscaling complejo, multi-region nativo o un modelo de despliegue ultra personalizable (ahí ya entras en terreno Kubernetes/nomad y compañía).
• Tu organización no quiere mantener ni ?un servidor más? (monitorización, hardening, backups, rotación de credenciales, etc.). Autoalojar es libertad, pero también responsabilidad.

Preguntas frecuentes

¿Puedo desplegar aplicaciones que no sean Node.js?
Sí: el planteamiento es multi-lenguaje siempre que tu app pueda ejecutarse en Docker (Python, PHP, Node.js, etc.).

¿Necesito abrir un puerto o tocar DNS sí o sí?
Necesitas DNS bien configurado antes de arrancar el servicio porque la emisión/validación de certificados depende de ello; la documentación detalla registros y consideraciones con Cloudflare.

¿Cómo se actualiza /dev/push en producción?
Proponen un script de update que crea backup y aplica cambios, y explican cómo hacer rollback restaurando desde el backup si algo falla.

¿Esto reemplaza a un CI/CD completo?
Depende del caso: /dev/push cubre bien el ?push to deploy?, pero si tu pipeline necesita pasos avanzados (tests complejos, matrices, aprobación por etapas, despliegues canary, etc.), lo normal es integrarlo con tu CI y usar /dev/push como capa de despliegue.

Fuente: Github dev Push