Vxero Neo

¿Qué es Vxero Neo?

Vxero Neo (Neo) es una herramienta de línea de comandos nativa de SSH para desplegar aplicaciones Docker en un VPS. Se conecta a tu servidor por SSH, configura Docker y Caddy, y despliega tus apps con HTTPS mediante auto-SSL, sin instalar un agente ni usar un plano de control separado.

Neo también gestiona las etapas del ciclo de vida de la aplicación desde el desarrollo local hasta staging y producción. Lee la configuración local de tu proyecto (incluyendo docker-compose.yml, .env y .neo.yml), construye y transfiere imágenes por SSH, realiza comprobaciones de salud y cambia el tráfico sin tiempo de inactividad.

Características clave

• Flujo de despliegue solo SSH (sin agente, sin dashboard): Neo se ejecuta en tu máquina local y se conecta al VPS vía SSH; aparte de Docker/Caddy para el runtime, no requiere herramientas adicionales en el servidor.
• Inicialización automática del servidor (Docker + Caddy): Durante el despliegue, Neo configura Docker y Caddy en el servidor destino para que tus contenedores se ejecuten y reciban tráfico HTTPS.
• De compose/config a un cambio en vivo: Neo lee tu config local, construye la imagen, la transfiere por SSH y luego cambia el tráfico tras las comprobaciones de salud; los contenedores antiguos siguen ejecutándose hasta el cambio.
• Dominio HTTPS instantáneo y opciones de certificados alternativas: Neo puede provisionar HTTPS usando sslip.io (sin DNS necesario) con --temp. Para dominios reales, usa Let’s Encrypt via Caddy (tras apuntar el DNS), o acepta tu propio certificado con --cert y --key.
• Generación de config y gestión de entornos: neo config generate escanea docker-compose.yml y genera automáticamente .neo.yml detectando el servicio de la app, sidecars, workers, variables de entorno y volúmenes. Neo también sincroniza env/estado con comandos como neo env y neo sync.
• Despliegues sin tiempo de inactividad estilo blue-green: Inicia los nuevos contenedores, espera las comprobaciones de salud y realiza el cambio de tráfico para que la versión anterior siga disponible hasta el corte.
• Workers, sidecars y volúmenes persistentes: Define workers de fondo y sidecars en .neo.yml para que se desplieguen junto a la app principal con volúmenes y variables de entorno compartidos. Declara volúmenes en .neo.yml para persistir datos entre redepliegues.
• Multi-servidor y configuraciones por entorno: Usa flags como --to staging para desplegar en staging o producción; cada entorno puede tener su propio dominio, variables de entorno y configuración SSL.

Cómo usar Vxero Neo

1. Prepara tu proyecto: Asegúrate de que tu app esté descrita con docker-compose.yml (y opcional .env).
2. Genera la config de despliegue de Neo: En el directorio de tu proyecto, ejecuta neo config generate. Neo escanea docker-compose.yml y escribe .neo.yml con los servicios detectados como la app, workers/sidecars (si están definidos/detectados), variables de entorno y volúmenes.
3. Desarrolla localmente (opcional pero soportado): Usa neo dev para envolver docker-compose con la carga de entorno de Neo desde .neo.yml.
4. Despliega por SSH: Ejecuta neo deploy apuntando a tu VPS. Neo construye la imagen desde tu Dockerfile (y config derivada de compose), la transfiere por SSH, realiza comprobaciones de salud y cambia el tráfico.
5. Activa HTTPS: Usa neo domain --temp para una URL HTTPS instantánea basada en sslip.io, o usa un dominio real con Let's Encrypt auto-SSL una vez apuntado el DNS, o proporciona --cert/--key para tu propio certificado.

Casos de uso

• Despliegues de apps Docker en un solo VM: Despliega una aplicación contenedorizada por VPS (p. ej., un servicio web) donde prefieras automatización basada en SSH en lugar de un orquestador de clúster.
• Staging → producción con config compartida: Usa la misma config en todos los entornos (vía generación de .neo.yml y carga de env), desplegando en staging y luego promoviendo a producción con dominios/SSL diferentes.
• Apps con sidecars y workers de fondo: Despliega una app principal junto a contenedores worker y sidecar definidos en .neo.yml, incluyendo variables de entorno y volúmenes compartidos.
• Proyectos que necesitan HTTPS rápido sin cambios de DNS: Usa neo domain --temp para obtener una URL HTTPS inmediata para pruebas con sslip.io, y luego cambia a un dominio real cuando el DNS esté listo.
• Lanzamientos sin tiempo de inactividad para equipos pequeños: Realiza actualizaciones estilo blue-green con comprobaciones de salud para que la versión antigua siga activa hasta que los nuevos contenedores estén listos.

Preguntas frecuentes

• ¿Neo instala un agente en mi servidor? No. Neo se ejecuta en tu máquina local y se conecta a tu VPS vía SSH. Lo único que se configura en el servidor son Docker y Caddy para el runtime de tu aplicación.

• Ya uso docker-compose. ¿Cómo paso a Neo? Ejecuta neo config generate en el directorio de tu proyecto. Neo escanea docker-compose.yml y genera automáticamente .neo.yml, luego puedes usar neo deploy para desplegar la app.

• ¿Qué proveedores de nube son compatibles? Neo puede desplegar en cualquier VPS con acceso SSH, como DigitalOcean, Hetzner, Linode, Vultr, AWS EC2, GCP y Azure. Neo despliega en una sola VM (no es un orquestador de clústeres multinodo como Kubernetes o Docker Swarm).

• ¿Cómo funciona HTTPS? Neo soporta neo domain --temp para HTTPS instantáneo vía sslip.io, neo domain app example.com para auto-SSL de Let’s Encrypt tras apuntar el DNS, y --cert/--key para usar tu propio certificado.

• ¿Puede Neo ejecutar workers en segundo plano y bases de datos? Los workers se declaran en .neo.yml y se despliegan como contenedores separados con la misma imagen, variables de entorno y volúmenes. Para bases de datos, Neo puede ejecutarlas como sidecars/servicios Docker para proyectos pequeños; para producción con usuarios reales, recomienda bases de datos gestionadas.

Alternativas

• Scripts manuales de despliegue Docker + Caddy: Si prefieres control total y ya tienes tu propia automatización de despliegue, puedes construir y transferir imágenes, ejecutar contenedores y gestionar Caddy/SSL tú mismo. Esto suele requerir más esfuerzo de configuración que el flujo de un solo comando de Neo.
• Docker Swarm o Kubernetes: Son orquestadores de clúster para despliegues multinodo. Difieren de Neo al enfocarse en orquestación entre clústeres en lugar de un solo VPS accesible por SSH.
• Otras pipelines CI/CD centradas en VPS: Puedes usar herramientas CI/CD genéricas para conectarte por SSH a un servidor, construir imágenes y reiniciar contenedores. Comparado con Neo, tendrías que manejar tú la generación de config, lógica de swaps sin downtime y integración HTTPS.
• Plataformas de contenedores gestionadas: Plataformas que gestionan enrutamiento y TLS pueden reducir pasos de infraestructura. Suelen sacrificar el modelo de despliegue “SSH-first, sin agente/control plane” descrito para Neo.