Vxero Neo

O que é Vxero Neo?

Vxero Neo (Neo) é uma ferramenta de linha de comando nativa de SSH para implantar aplicações Docker em um VPS. Ela se conecta ao seu servidor via SSH, configura Docker e Caddy, e implanta suas apps com HTTPS via auto-SSL — sem instalar um agente ou usar um plano de controle separado.

Neo também gerencia as etapas do ciclo de vida da aplicação, desde o desenvolvimento local até staging e produção. Ela lê a configuração local do seu projeto (incluindo docker-compose.yml, .env e .neo.yml), constrói e transfere imagens via SSH, realiza verificações de saúde e faz swap de tráfego com zero downtime.

Principais Recursos

• Fluxo de implantação apenas via SSH (sem agente, sem dashboard): Neo roda na sua máquina local e se conecta ao VPS via SSH; além de Docker/Caddy para o runtime, não requer ferramentas adicionais no servidor.
• Inicialização automática do servidor (Docker + Caddy): Durante a implantação, Neo configura Docker e Caddy no servidor alvo para que seus contêineres rodem e recebam tráfego HTTPS.
• De compose/config para um swap ao vivo: Neo lê sua config local, constrói a imagem, transfere via SSH, e então faz o swap de tráfego após verificações de saúde; contêineres antigos continuam rodando até o swap.
• Domínio HTTPS instantâneo e opções alternativas de certificado: Neo pode provisionar HTTPS usando sslip.io (sem DNS necessário) com --temp. Para domínios reais, usa Let’s Encrypt via Caddy (após apontar DNS), ou aceita seu próprio cert com --cert e --key.
• Geração de config e gerenciamento de ambiente: neo config generate escaneia docker-compose.yml e gera .neo.yml automaticamente detectando serviço da app, sidecars, workers, variáveis de ambiente e volumes. Neo também sincroniza env/estado via comandos como neo env e neo sync.
• Implantações zero-downtime no estilo blue-green: Inicia os novos contêineres, aguarda verificações de saúde e então faz o swap de tráfego, mantendo a versão anterior disponível até o corte.
• Workers, sidecars e volumes persistentes: Defina workers em background e sidecars em .neo.yml para implantar junto com a app principal, com volumes e vars de ambiente compartilhados. Declare volumes em .neo.yml para persistir dados entre reimplantações.
• Multi-servidor e configurações por ambiente: Use flags como --to staging para implantar em staging ou produção; cada ambiente pode ter seu domínio, variáveis de ambiente e config SSL próprios.

Como Usar Vxero Neo

1. Prepare seu projeto: Certifique-se de que sua app está descrita com docker-compose.yml (e opcional .env).
2. Gere a config de implantação do Neo: No diretório do projeto, rode neo config generate. Neo escaneia docker-compose.yml e cria .neo.yml com serviços detectados como app, workers/sidecars (se definidos/detectados), variáveis de ambiente e volumes.
3. Desenvolva localmente (opcional, mas suportado): Use neo dev para envolver docker-compose com carregamento de ambiente do Neo a partir de .neo.yml.
4. Implante via SSH: Rode neo deploy mirando seu VPS. Neo constrói a imagem a partir do seu Dockerfile (e config derivada do compose), transfere via SSH, realiza verificações de saúde e faz swap de tráfego.
5. Ative HTTPS: Use neo domain --temp para uma URL HTTPS instantânea baseada em sslip.io, ou use um domínio real com Let's Encrypt auto-SSL após apontar DNS, ou forneça --cert/--key para seu próprio certificado.

Casos de Uso

• Implantações de apps Docker em VM única: Implante uma aplicação containerizada por VPS (ex.: um serviço web) onde você quer automação via SSH em vez de orquestrador de cluster.
• Staging → produção com config compartilhada: Use a mesma config entre ambientes (via geração de .neo.yml e carregamento de env), implantando em staging e promovendo para produção com domínios/SSL diferentes.
• Apps com sidecars e workers em background: Implante uma app principal junto com contêineres worker e sidecar definidos em .neo.yml, incluindo vars de ambiente e volumes compartilhados.
• Projetos que precisam de HTTPS rápido sem mudanças de DNS: Use neo domain --temp para uma URL HTTPS imediata para testes com sslip.io, depois mude para domínio real quando DNS estiver pronto.
• Lançamentos zero-downtime para equipes pequenas: Realize atualizações no estilo blue-green com verificações de saúde para manter a versão antiga ativa até os novos contêineres estarem prontos.

FAQ

• O Neo instala um agente no meu servidor? Não. O Neo roda na sua máquina local e se conecta ao VPS via SSH. As únicas coisas configuradas no servidor são Docker e Caddy para o runtime da sua aplicação.

• Já uso docker-compose. Como migro para o Neo? Execute neo config generate no diretório do seu projeto. O Neo analisa o docker-compose.yml e gera automaticamente o .neo.yml, depois você pode usar neo deploy para implantar a app.

• Quais provedores de nuvem são suportados? O Neo implanta em qualquer VPS com acesso SSH, como DigitalOcean, Hetzner, Linode, Vultr, AWS EC2, GCP e Azure. O Neo implanta em uma única VM (não é um orquestrador de cluster multi-nó como Kubernetes ou Docker Swarm).

• Como funciona o HTTPS? O Neo suporta neo domain --temp para HTTPS instantâneo via sslip.io, neo domain app example.com para auto-SSL Let’s Encrypt após apontar o DNS, e --cert/--key para usar seu próprio certificado.

• O Neo roda workers em background e bancos de dados? Workers podem ser declarados no .neo.yml e são implantados como containers separados usando a mesma imagem, vars de ambiente e volumes. Para bancos de dados, o Neo pode rodá-los como sidecars/serviços Docker para projetos menores; para produção com usuários reais, recomenda bancos gerenciados.

Alternativas

• Scripts manuais de deploy Docker + Caddy: Se prefere controle total e já tem automação própria, você pode buildar e transferir imagens, rodar containers e gerenciar Caddy/SSL manualmente. Isso geralmente exige mais esforço que o fluxo de comando único do Neo.
• Docker Swarm ou Kubernetes: São orquestradores de cluster para deploys multi-nó. Diferem do Neo por focarem em orquestração em clusters em vez de um único VPS acessível via SSH.
• Pipelines CI/CD centrados em VPS: Você pode usar ferramentas CI/CD genéricas para SSH em um servidor, buildar imagens e reiniciar containers. Comparado ao Neo, você gerencia geração de config, lógica de swap sem downtime e integração HTTPS sozinho.
• Plataformas gerenciadas de containers: Plataformas que gerenciam roteamento e TLS reduzem passos de infraestrutura. Elas geralmente sacrificam o modelo de deploy “SSH-first, sem agente/control plane” descrito para o Neo.