Vxero Neo

Qu’est-ce que Vxero Neo ?

Vxero Neo (Neo) est un outil en ligne de commande natif SSH pour déployer des applications Docker sur un VPS. Il se connecte à votre serveur via SSH, installe Docker et Caddy, et déploie vos apps avec HTTPS via auto-SSL — sans installer d’agent ni utiliser de plan de contrôle séparé.

Neo gère aussi les étapes du cycle de vie des applications, du développement local à l’intégration et à la production. Il lit votre configuration de projet local (y compris docker-compose.yml, .env et .neo.yml), construit et transfère les images via SSH, effectue des vérifications de santé, et bascule le trafic sans interruption.

Fonctionnalités principales

• Flux de déploiement SSH uniquement (pas d’agent, pas de tableau de bord) : Neo s’exécute sur votre machine locale et se connecte à votre VPS via SSH ; hormis Docker/Caddy pour l’exécution, il ne nécessite aucun outil serveur supplémentaire.
• Initialisation automatique du serveur (Docker + Caddy) : Lors du déploiement, Neo configure Docker et Caddy sur le serveur cible pour que vos conteneurs puissent s’exécuter et recevoir du trafic HTTPS.
• De compose/config à un basculement en direct : Neo lit votre config locale, construit l’image, la transfère via SSH, puis bascule le trafic après vérifications de santé ; les anciens conteneurs continuent de tourner jusqu’au basculement.
• Domaine HTTPS instantané et options de certificats alternatives : Neo peut provisionner HTTPS via sslip.io (sans DNS requis) avec --temp. Pour de vrais domaines, il utilise Let’s Encrypt via Caddy (après pointage DNS), ou accepte votre propre certificat avec --cert et --key.
• Génération de config et gestion d’environnement : neo config generate analyse docker-compose.yml et génère automatiquement .neo.yml en détectant le service app, les sidecars, workers, variables d’environnement et volumes. Neo peut aussi synchroniser env/état via des commandes comme neo env et neo sync.
• Déploiements sans interruption style blue-green : Il démarre les nouveaux conteneurs, attend les vérifications de santé, puis effectue le basculement du trafic pour que la version précédente reste disponible jusqu’au passage.
• Workers, sidecars et volumes persistants : Définissez des workers en arrière-plan et sidecars dans .neo.yml pour qu’ils se déploient avec l’app principale, avec volumes et variables d’environnement partagés. Déclarez les volumes dans .neo.yml pour persister les données lors des redéploiements.
• Multi-serveurs et paramètres par environnement : Utilisez des flags comme --to staging pour déployer en staging ou production ; chaque environnement peut avoir son propre domaine, variables d’environnement et config SSL.

Comment utiliser Vxero Neo

1. Préparez votre projet : Assurez-vous que votre app est décrite avec docker-compose.yml (et .env optionnel).
2. Générez la config de déploiement Neo : Dans votre répertoire de projet, exécutez neo config generate. Neo analyse docker-compose.yml et crée .neo.yml avec les services détectés comme l’app, workers/sidecars (s’ils sont définis/détectés), variables d’environnement et volumes.
3. Développez localement (optionnel mais pris en charge) : Utilisez neo dev pour encapsuler docker-compose avec le chargement d’environnement de .neo.yml par Neo.
4. Déployez via SSH : Exécutez neo deploy en visant votre VPS. Neo construit l’image à partir de votre Dockerfile (et config dérivée de compose), la transfère via SSH, puis effectue les vérifications de santé et bascule le trafic.
5. Activez HTTPS : Utilisez neo domain --temp pour une URL HTTPS instantanée basée sur sslip.io, ou un vrai domaine avec auto-SSL Let’s Encrypt une fois le DNS pointé, ou fournissez --cert/--key pour votre propre certificat.

Cas d’usage

• Déploiements d’apps Docker sur VM unique : Déployez une application conteneurisée par VPS (ex. : un service web) où vous préférez l’automatisation SSH plutôt qu’un orchestrateur de cluster.
• Staging → production avec config partagée : Utilisez la même config sur tous les environnements (via génération .neo.yml et chargement env), en déployant en staging puis en promouvant en production avec domaines/SSL différents.
• Apps avec sidecars et workers en arrière-plan : Déployez une app principale avec des conteneurs worker et sidecar définis dans .neo.yml, incluant variables d’environnement et volumes partagés.
• Projets nécessitant HTTPS rapide sans changement DNS : Utilisez neo domain --temp pour une URL HTTPS immédiate de test avec sslip.io, puis passez à un vrai domaine quand le DNS est prêt.
• Sorties sans interruption pour petites équipes : Effectuez des mises à jour style blue-green avec vérifications de santé pour que l’ancienne version reste active jusqu’à ce que les nouveaux conteneurs soient prêts.

FAQ

• Neo installe-t-il un agent sur mon serveur ? Non. Neo s’exécute sur votre machine locale et se connecte à votre VPS via SSH. Seuls Docker et Caddy sont installés sur le serveur pour l’exécution de votre application.

• J’utilise déjà docker-compose. Comment passer à Neo ? Exécutez neo config generate dans le répertoire de votre projet. Neo analyse docker-compose.yml et génère automatiquement .neo.yml, puis vous pouvez utiliser neo deploy pour déployer l’app.

• Quels fournisseurs cloud sont pris en charge ? Neo peut déployer sur n’importe quel VPS offrant un accès SSH, comme DigitalOcean, Hetzner, Linode, Vultr, AWS EC2, GCP et Azure. Neo déploie sur une seule VM (ce n’est pas un orchestrateur de cluster multi-nœuds comme Kubernetes ou Docker Swarm).

• Comment fonctionne HTTPS ? Neo prend en charge neo domain --temp pour un HTTPS instantané via sslip.io, neo domain app example.com pour un auto-SSL Let’s Encrypt après pointage DNS, et --cert/--key pour utiliser votre propre certificat.

• Neo peut-il exécuter des workers en arrière-plan et des bases de données ? Les workers peuvent être déclarés dans .neo.yml et sont déployés comme conteneurs séparés avec la même image, variables d’environnement et volumes. Pour les bases de données, Neo peut les exécuter comme sidecars/services Docker pour les petits projets ; pour la production avec de vrais utilisateurs, il recommande des bases de données managées.

Alternatives

• Scripts de déploiement manuels Docker + Caddy : Si vous préférez un contrôle total et avez déjà votre propre automatisation de déploiement, vous pouvez construire et transférer des images, exécuter des conteneurs et gérer Caddy/SSL vous-même. Cela demande généralement plus d’efforts de configuration que le workflow en une commande de Neo.
• Docker Swarm ou Kubernetes : Ce sont des orchestrateurs de cluster pour déploiements multi-nœuds. Ils diffèrent de Neo en ciblant l’orchestration sur des clusters plutôt qu’un seul VPS accessible via SSH.
• Autres pipelines CI/CD centrés sur VPS : Vous pouvez utiliser des outils CI/CD génériques pour se connecter en SSH à un serveur, construire des images et redémarrer des conteneurs. Par rapport à Neo, vous gérez vous-même la génération de config, la logique de basculement sans interruption et l’intégration HTTPS.
• Plateformes de conteneurs managées : Les plateformes qui gèrent le routage et TLS réduisent les étapes d’infrastructure. Elles échangent généralement le modèle de déploiement « SSH-first, sans agent/plan de contrôle » décrit pour Neo.