Durante años, muchos equipos (y no solo “techies”) se han acostumbrado a lo fácil: conectar un repositorio, pulsar deploy y olvidarse del servidor. Vercel, Netlify o Render han hecho eso muy bien. El problema llega cuando ese “olvido” empieza a doler: costes que crecen sin avisar, limitaciones por plataforma, dependencias con un proveedor concreto (vendor lock-in) o simplemente la necesidad de desplegar en tu propia infraestructura por cumplimiento, privacidad o sentido común.
Ahí es donde entra /dev/push: una plataforma open source y autoalojable para construir y desplegar aplicaciones “push-to-deploy” desde GitHub, con el objetivo de acercar una experiencia tipo Vercel a tu propio servidor.
Qué es exactamente /dev/push (y por qué llama la atención)
Según su documentación oficial, /dev/push se presenta como una alternativa autoalojada a servicios tipo Vercel/Render/Netlify, capaz de desplegar aplicaciones de varios lenguajes (Python, Node.js, PHP, etc.) siempre que puedan ejecutarse en Docker. La idea es clara: experiencia sencilla, sin convertirte en “administrador a tiempo completo” para lo básico del despliegue.
Además, el proyecto está licenciado bajo MIT, lo que facilita su adopción en entornos comerciales (siempre respetando las condiciones de la licencia).
Las funciones clave, contadas sin humo
En su README, /dev/push resume el “paquete” con bastante precisión:
- Despliegues basados en Git: push a GitHub y despliegue automático con actualizaciones sin caída y rollback rápido.
- Multi-lenguaje: soporta cualquier stack que encaje en Docker.
- Gestión de entornos: mapeo por ramas, variables cifradas y entornos separados (por ejemplo, staging y production).
- Observabilidad práctica: logs de build y runtime “en vivo” y buscables.
- Trabajo en equipo: control de accesos por roles e invitaciones.
- Dominios y SSL: dominios personalizados y certificados automáticos con Let’s Encrypt.
En otras palabras: lo que muchos esperan de una plataforma PaaS moderna… pero en tu propia máquina.
Cómo funciona por debajo (lo importante: no es magia)
La propia documentación lo resume sin misterio: “por debajo, es Docker”. /dev/push recibe webhooks de GitHub, construye/arranca contenedores siguiendo la configuración del proyecto y, cuando todo está listo, hace el cambio al nuevo despliegue. Esa mecánica es la que permite el enfoque de “cero downtime” en escenarios típicos.
Requisitos reales para montarlo (lo que nadie te dice en los anuncios)
Para funcionar, /dev/push pide una base razonable de infraestructura y “piezas” externas:
- Servidor con Ubuntu 20.04+ o Debian 11+ y acceso por SSH con sudo.
- DNS (se recomienda Cloudflare en la documentación).
- Cuenta de GitHub para crear una GitHub App (login y acceso a repos).
- Proveedor de email (en los docs se cita Resend para correos de login e invitaciones).
Y aquí hay un matiz que suele dar guerra: certificados TLS y DNS. La guía indica que, si usas Cloudflare, configures SSL/TLS en “Full (strict)” y explica cuándo conviene HTTP-01 o DNS-01 (especialmente para comodines).
Instalación rápida: lo básico que debes entender antes de “pegar el comando”
El proyecto ofrece instalación automatizada (tipo script installer) y arranque como servicio. A grandes rasgos, la secuencia oficial es: ejecutar el instalador, crear la GitHub App, configurar el .env, ajustar DNS (registro A y wildcard) y arrancar el servicio.
Un consejo de sentido común: si vas a ejecutar un “curl | bash”, hazlo con cabeza (revisar el script, fijar versión/commit cuando sea posible, y no hacerlo en un servidor con datos críticos sin validar). Esto no es una crítica a /dev/push, es higiene básica en cualquier automatización.
¿Para quién encaja mejor?
/dev/push tiene pinta de encajar especialmente bien en estos escenarios:
- Equipos que quieren desplegar apps internas o de cliente sin depender de un proveedor PaaS externo.
- Proyectos que necesitan entornos separados por rama y una experiencia de despliegue repetible.
- Pequeñas empresas que quieren un “panel único” con logs, dominios, permisos y despliegues sin montar Kubernetes.
Y puede no ser la mejor opción si tu caso exige redes muy personalizadas, orquestación compleja o políticas corporativas donde todo debe integrarse con herramientas internas específicas. En esos casos, quizá busques otra capa (o un enfoque más “infra”).
El punto legal y operativo: cuando te lo autoalojas, te lo comes
Autoalojar tiene una ventaja enorme: control. Y una consecuencia directa: responsabilidad.
- Tú gestionas parches del sistema, exposición de puertos, copias de seguridad, rotación de secretos y seguridad del acceso.
- La guía incluye recomendaciones prácticas relacionadas con DNS/Let’s Encrypt y escenarios típicos con Cloudflare.
- El README también menciona endurecimiento del servidor (por ejemplo, UFW/fail2ban y deshabilitar root por SSH) como buenas prácticas recomendables.
No es para asustar: es para que nadie lo monte “en 10 minutos” y luego lo deje sin mantenimiento.
Preguntas frecuentes
¿/dev/push sirve para desplegar WordPress, Laravel o apps PHP “clásicas”?
Si tu aplicación puede empaquetarse y ejecutarse en Docker, el enfoque de /dev/push está pensado precisamente para eso, incluyendo PHP.
¿Puedo usar /dev/push en una empresa con varios entornos (staging/producción) y ramas?
Sí: una de sus bazas es la gestión de múltiples entornos con mapeo por rama y variables de entorno cifradas.
¿Necesito Cloudflare obligatoriamente?
No necesariamente, pero la documentación lo recomienda y detalla configuraciones de SSL/TLS y validación de certificados que suelen simplificar la vida en despliegues con dominios y comodines.
¿Qué necesito para los certificados SSL y dominios personalizados?
El proyecto contempla dominios personalizados y certificados automáticos con Let’s Encrypt, y la guía explica opciones de desafío (HTTP-01/DNS-01) según tu caso.
