Vxero Neo

Che cos'è Vxero Neo?

Vxero Neo (Neo) è uno strumento da linea di comando nativo SSH per distribuire applicazioni Docker su un VPS. Si connette al tuo server via SSH, configura Docker e Caddy, e distribuisce le tue app con HTTPS tramite auto-SSL—senza installare un agent o usare un control plane separato.

Neo gestisce anche le fasi del ciclo di vita dell'applicazione dallo sviluppo locale fino a staging e produzione. Legge la configurazione del tuo progetto locale (incluso docker-compose.yml, .env e .neo.yml), costruisce e trasferisce le immagini via SSH, esegue health check e swap del traffico senza downtime.

Caratteristiche Principali

• Flusso di deployment solo SSH (no agent, no dashboard): Neo gira sulla tua macchina locale e si connette al tuo VPS via SSH; oltre a Docker/Caddy per il runtime, non richiede tooling server-side aggiuntivo.
• Inizializzazione server automatizzata (Docker + Caddy): Durante il deployment, Neo configura Docker e Caddy sul server target così i tuoi container possono girare e ricevere traffico HTTPS.
• Da compose/config a switch live: Neo legge la tua config locale, costruisce l'immagine, la trasferisce via SSH, poi swap del traffico dopo health check; i container vecchi continuano a girare fino al switch.
• HTTPS domain istantaneo e opzioni certificate alternative: Neo può provisionare HTTPS usando sslip.io (no DNS necessario) con --temp. Per domini reali, usa Let’s Encrypt via Caddy (dopo aver puntato il DNS), o accetta il tuo cert con --cert e --key.
• Generazione config e gestione environment: neo config generate scansiona docker-compose.yml e genera automaticamente .neo.yml rilevando app service, sidecar, worker, variabili d'ambiente e volumi. Neo può anche sincronizzare env/state con comandi come neo env e neo sync.
• Deployment zero-downtime stile blue-green: Avvia i nuovi container, aspetta i health check, poi esegue lo swap del traffico così la versione precedente resta disponibile fino al cutover.
• Worker, sidecar e volumi persistenti: Definisci worker in background e sidecar in .neo.yml così si deployano alongside l'app principale con volumi e variabili d'ambiente condivisi. Dichiarare volumi in .neo.yml per persistere i dati tra redeploy.
• Multi-server e impostazioni per environment: Usa flag come --to staging per deployare su staging o production; ogni environment può avere il suo dominio, variabili d'ambiente e configurazione SSL.

Come Usare Vxero Neo

1. Prepara il tuo progetto: Assicurati che la tua app sia descritta con docker-compose.yml (e opzionale .env).
2. Genera la config di deployment di Neo: Nella directory del tuo progetto, esegui neo config generate. Neo scansiona docker-compose.yml e scrive .neo.yml con i servizi rilevati come app, worker/sidecar (se definiti/rilevati), variabili d'ambiente e volumi.
3. Sviluppo locale (opzionale ma supportato): Usa neo dev per wrappare docker-compose con il caricamento environment di Neo da .neo.yml.
4. Deploy via SSH: Esegui neo deploy puntando al tuo VPS. Neo costruisce l'immagine dal tuo Dockerfile (e config derivata da compose), la trasferisce via SSH, poi esegue health check e swap del traffico.
5. Abilita HTTPS: Usa neo domain --temp per un URL HTTPS istantaneo basato su sslip.io, o usa un dominio reale con Let's Encrypt auto-SSL una volta puntato il DNS, o fornisci --cert/--key per il tuo certificato.

Casi d'Uso

• Deployment app Docker single-VM: Distribuisci un'applicazione containerizzata per VPS (es. un web service) dove vuoi automazione basata su SSH invece di un orchestrator di cluster.
• Staging → production con config condivisa: Usa la stessa config tra environment (via generazione .neo.yml e caricamento env), deployando su staging e poi promuovendo su production con domini/SSL diversi.
• App con sidecar e worker in background: Deploya un'app principale alongside container worker e sidecar definiti in .neo.yml, inclusi variabili d'ambiente e volumi condivisi.
• Progetti che necessitano HTTPS rapido senza cambiamenti DNS: Usa neo domain --temp per ottenere un URL HTTPS immediato per test con sslip.io, poi passa a un dominio reale quando il DNS è pronto.
• Release zero-downtime per piccoli team: Esegui update stile blue-green con health check così la vecchia versione resta up fino a quando i nuovi container non sono pronti.

FAQ

• Neo installa un agent sul mio server? No. Neo gira sulla tua macchina locale e si connette al tuo VPS via SSH. Sul server vengono configurati solo Docker e Caddy per il runtime della tua applicazione.

• Uso già docker-compose. Come passo a Neo? Esegui neo config generate nella directory del tuo progetto. Neo scansiona docker-compose.yml e genera automaticamente .neo.yml, poi puoi usare neo deploy per distribuire l'app.

• Quali provider cloud sono supportati? Neo può distribuire su qualsiasi VPS con accesso SSH, come DigitalOcean, Hetzner, Linode, Vultr, AWS EC2, GCP e Azure. Neo distribuisce su una singola VM (non è un orchestratore di cluster multi-nodo come Kubernetes o Docker Swarm).

• Come funziona HTTPS? Neo supporta neo domain --temp per HTTPS istantaneo via sslip.io, neo domain app example.com per auto-SSL Let’s Encrypt dopo aver puntato il DNS, e --cert/--key per usare il tuo certificato.

• Neo può eseguire worker in background e database? I worker possono essere dichiarati in .neo.yml e distribuiti come container separati usando la stessa immagine, variabili d'ambiente e volumi. Per i database, Neo può eseguirli come sidecar/servizi Docker per progetti piccoli; per produzione con utenti reali, raccomanda database gestiti.

Alternative

• Script manuali di deploy Docker + Caddy: Se preferisci il controllo totale e hai già la tua automazione di deploy, puoi buildare e trasferire immagini, eseguire container e gestire Caddy/SSL da solo. Questo richiede tipicamente più effort di setup rispetto al workflow single-command di Neo.
• Docker Swarm o Kubernetes: Sono orchestratori di cluster per deploy multi-nodo. Differiscono da Neo perché mirano all'orchestrazione su cluster anziché su un singolo VPS accessibile via SSH.
• Altre pipeline CI/CD VPS-centriche: Puoi usare tool CI/CD generici per SSH su un server, buildare immagini e riavviare container. Rispetto a Neo, dovresti gestire da solo generazione config, logica di switch zero-downtime e integrazione HTTPS.
• Piattaforme container gestite: Piattaforme che gestiscono routing e TLS riducono i passi infrastrutturali. Di solito rinunciano al modello di deploy “SSH-first, senza agent/control plane” descritto per Neo.