Gangway ofrece URLs de vista previa efímeras para entornos Docker autoalojados

Charles Barnes ha lanzado gangway, una herramienta de código abierto que asigna URLs HTTPS públicas a aplicaciones contenedorizadas que se ejecutan en infraestructuras autoalojadas. Publicado en GitHub a finales de septiembre de 2026, el proyecto está dirigido a desarrolladores que desean la comodidad de las plataformas de vista previa alojadas, pero prefieren mantener sus cargas de trabajo en su propio hardware. Admite despliegues mediante pull requests, agentes de IA o subidas manuales, creando entornos temporales que caducan automáticamente.

Qué ha ocurrido

Gangway actúa como un único proceso en un host Docker estándar, eliminando la necesidad de sistemas complejos de orquestación como Kubernetes. Cuando un desarrollador abre una pull request, un agente de IA activa un despliegue o un usuario sube archivos a través de la interfaz web, la herramienta levanta una pila de Docker Compose. A continuación, asigna un subdominio único bajo un dominio comodín configurado, como shop-pr-142.preview.example.com. Esta URL se vuelve accesible públicamente de inmediato, permitiendo a los interesados revisar cambios en el frontend, probar compilaciones o ver artefactos generados sin acceder a redes internas.

El sistema gestiona todo el ciclo de vida de estas vistas previas. Se encarga del aprovisionamiento de certificados SSL utilizando Let’s Encrypt mediante desafíos DNS-01, garantizando que cada vista previa se sirva sobre HTTPS sin alcanzar los límites de uso asociados a los certificados por vista previa. Las vistas previas están diseñadas para ser efímeras; entran en suspensión tras periodos de inactividad para ahorrar recursos y se eliminan completamente cuando se cierra la pull request asociada o expira su tiempo de vida (TTL). La herramienta también admite sitios estáticos y artefactos directamente, sirviéndolos sin requerir un contenedor, lo que permite tiempos de despliegue de milisegundos para documentos simples o paneles de control.

Detalles clave

• Métodos de despliegue: Admite tres puntos de entrada: pull requests de GitHub con enlaces de comentarios persistentes, agentes de IA a través del Model Context Protocol (MCP) y subidas manuales mediante UI o API REST.
• Requisitos de infraestructura: Se ejecuta en un host Docker simple con Compose; no se requiere Kubernetes. Necesita un servidor con IP pública y un dominio con registros DNS de comodín.
• Gestión de certificados: Utiliza un único certificado de comodín para todas las vistas previas para evitar los límites de uso de Let's Encrypt, o se integra con proxies inversos como Caddy para TLS bajo demanda.
• Aislamiento de recursos: Aplica políticas de seguridad eliminando capacidades de Linux, limitando memoria y procesos, y rechazando modos privilegiados o acceso a la red del host para los contenedores de vista previa.
• Soporte de bases de datos: Aprovisiona automáticamente instancias desechables de Postgres, MySQL o Redis para las vistas previas, inyectando cadenas de conexión como variables de entorno y eliminándolas al finalizar.
• Control de acceso: Ofrece múltiples niveles de visibilidad, incluyendo público, no listado, protegido con contraseña o restringido a usuarios autenticados, con permisos granulares para tokens de API y clientes OAuth.

Antecedentes

Los entornos de vista previa efímeros son una función estándar en plataformas de hosting gestionadas como Vercel o Netlify. Permiten a los equipos compartir versiones funcionales de una aplicación para cada cambio de código. Sin embargo, estos servicios a menudo bloquean a los usuarios en frameworks específicos, cobran según el uso y almacenan datos en servidores de terceros. Para las organizaciones que se autoalojan debido a cumplimiento normativo, costes o preferencias técnicas, replicar este flujo de trabajo tradicionalmente requiere un esfuerzo significativo de DevOps. Configurar DNS dinámico, gestionar certificados SSL para cientos de subdominios temporales y orquestar ciclos de vida de contenedores suele exigir un clúster de Kubernetes o scripts personalizados complejos.

Gangway simplifica esto aprovechando las capacidades existentes de Docker Compose y una arquitectura de proxy ligera. Utiliza SQLite como base de datos de estado, rastreando qué contenedores corresponden a qué URLs. Al despachar solicitudes basándose en el encabezado HTTP Host, enruta el tráfico al contenedor correcto sin necesidad de una malla de servicios pesada. Este enfoque hace viable que pequeños equipos o desarrolladores individuales ejecuten una plataforma de "preview-as-a-service" en una única máquina virtual o servidor bare-metal.

Por qué importa

Para los equipos que ejecutan su propio software, gangway reduce la fricción entre desarrollo y revisión. En lugar de pedir a los colegas que extraigan ramas localmente o desplegar en un servidor de staging compartido donde los cambios podrían entrar en conflicto, los desarrolladores pueden compartir una URL única y aislada. Esto es particularmente valioso para el trabajo en frontend, donde la retroalimentación visual es crítica, o para artefactos generados por IA como gráficos y documentos que necesitan compartirse inmediatamente. La capacidad de levantar pilas completas con bases de datos significa que los cambios en backend también pueden revisarse en contexto, reflejando el comportamiento de producción más fielmente que las vistas previas estáticas.

La integración con agentes de IA a través de MCP aborda un patrón de flujo de trabajo creciente. A medida que los desarrolladores utilizan herramientas como Claude Code o Cursor para generar código y artefactos, gangway proporciona un destino nativo para estas salidas. Un agente puede desplegar un panel de control o prototipo generado y devolver una URL en vivo instantáneamente. Esto cierra la brecha entre la asistencia local de IA y la revisión colaborativa, asegurando que el trabajo generado por IA sea fácilmente accesible para los miembros humanos del equipo sin pasos manuales de subida o servicios temporales de intercambio de archivos.

La seguridad y la gestión de recursos también se manejan de forma práctica. Al aplicar estrictos límites de contenedor y aislar las vistas previas del sistema anfitrión, la herramienta mitiga los riesgos asociados con la ejecución de código no confiable o contribuciones externas. La limpieza automática de vistas previas inactivas evita fugas de recursos, un problema común cuando los equipos gestionan manualmente entornos temporales. Esta automatización permite a los líderes de TI ofrecer funciones amigables para desarrolladores sin aumentar la carga operativa para los administradores de sistemas.

Qué puedes hacer

• Probar localmente: Instala gangway en un portátil usando la flag --local para crear vistas previas en preview.localhost sin necesitar un dominio público ni configuración de DNS.
• Configurar DNS: Establece un registro DNS de comodín (por ejemplo, *.preview.example.com) apuntando a la dirección IP de tu servidor para habilitar vistas previas accesibles públicamente.
• Integrar con GitHub: Usa el flujo de creación de GitHub App con un clic para conectar repositorios, habilitando despliegues automáticos de vistas previas para cada pull request.
• Conectar agentes de IA: Sigue las instrucciones de configuración proporcionadas para Claude Code, Cursor o VS Code para permitir que las herramientas de IA desplieguen artefactos directamente en tu instancia de gangway.
• Asegurar el acceso: Revisa la documentación de seguridad para configurar restricciones de red, establecer protección con contraseña para vistas previas sensibles y gestionar permisos de tokens de API.
• Monitorear recursos: Ajusta los límites de memoria y CPU en las variables de entorno para asegurar que las vistas previas no consuman recursos excesivos en tu servidor anfitrión.