Vxero Neo

Was ist Vxero Neo?

Vxero Neo (Neo) ist ein SSH-natives Kommandozeilen-Tool zum Bereitstellen von Docker-Anwendungen auf einem VPS. Es verbindet sich per SSH mit Ihrem Server, richtet Docker und Caddy ein und stellt Ihre Apps mit HTTPS via Auto-SSL bereit – ohne Agenten-Installation oder separaten Control Plane.

Neo verwaltet zudem den gesamten Anwendungs-Lebenszyklus von der lokalen Entwicklung über Staging bis Production. Es liest Ihre lokale Projektkonfiguration (inkl. docker-compose.yml, .env und .neo.yml), baut Images und überträgt sie per SSH, führt Health Checks durch und wechselt den Traffic zero-downtime.

Wichtige Features

• SSH-only Deployment-Flow (kein Agent, kein Dashboard): Neo läuft lokal auf Ihrem Rechner und verbindet sich per SSH mit dem VPS; abgesehen von Docker/Caddy für die Runtime braucht es keine zusätzliche Server-Software.
• Automatisierte Server-Initialisierung (Docker + Caddy): Beim Deployment richtet Neo Docker und Caddy auf dem Zielserver ein, damit Ihre Container laufen und HTTPS-Traffic empfangen können.
• Von Compose/Config zum live Switch: Neo liest Ihre lokale Config, baut das Image, überträgt es per SSH, führt Health Checks durch und wechselt den Traffic; alte Container laufen weiter bis zum Switch.
• Sofortiges HTTPS-Domain und alternative Zertifikatsoptionen: Neo stellt HTTPS mit sslip.io (kein DNS nötig) via --temp bereit. Für echte Domains nutzt es Let’s Encrypt via Caddy (nach DNS-Weiterleitung) oder akzeptiert eigene Certs mit --cert und --key.
• Config-Generierung und Environment-Management: neo config generate scannt docker-compose.yml und erzeugt automatisch .neo.yml mit erkannten App-Services, Sidecars, Workern, Env-Variablen und Volumes. Neo syncronisiert Env/State via neo env und neo sync.
• Blue-Green-Style Zero-Downtime-Deploys: Es startet neue Container, wartet auf Health Checks und führt dann den Traffic-Switch durch, sodass die alte Version bis zum Cutover verfügbar bleibt.
• Worker, Sidecars und persistente Volumes: Definieren Sie Background-Worker und Sidecars in .neo.yml, damit sie mit der Haupt-App und geteilten Volumes/Env-Vars deployen. Volumes in .neo.yml sorgen für Datenpersistenz über Redeploys hinweg.
• Multi-Server und per-Environment-Einstellungen: Nutzen Sie Flags wie --to staging für Staging oder Production; jede Environment kann eigene Domains, Env-Variablen und SSL-Konfigs haben.

So nutzen Sie Vxero Neo

1. Projekt vorbereiten: Stellen Sie sicher, dass Ihre App mit docker-compose.yml (und optional .env) beschrieben ist.
2. Neo-Deployment-Config generieren: Im Projektverzeichnis neo config generate ausführen. Neo scannt docker-compose.yml und schreibt .neo.yml mit erkannten Services wie App, Worker/Sidecars (falls definiert/erkannt), Env-Variablen und Volumes.
3. Lokal entwickeln (optional, aber unterstützt): neo dev wrappt docker-compose mit Neo-Environment-Loading aus .neo.yml.
4. Per SSH deployen: neo deploy auf Ihren VPS ausführen. Neo baut das Image aus Dockerfile (und compose-abgeleiteter Config), überträgt es per SSH, führt Health Checks durch und wechselt Traffic.
5. HTTPS aktivieren: neo domain --temp für sslip.io-basierten instant HTTPS-URL, oder echte Domain mit Let's Encrypt Auto-SSL nach DNS-Weiterleitung, oder --cert/--key für eigenes Zertifikat.

Anwendungsfälle

• Single-VM Docker-App-Deploys: Eine containerisierte App pro VPS deployen (z. B. Web-Service), mit SSH-basierter Automatisierung statt Cluster-Orchestrator.
• Staging → Production mit shared Config: Gleiche Config über Environments (via .neo.yml-Generierung und Env-Loading), Deploy nach Staging und Promotion zu Production mit unterschiedlichen Domains/SSL.
• Apps mit Sidecars und Background-Workern: Haupt-App mit Worker- und Sidecar-Containern aus .neo.yml deployen, inkl. geteilter Env-Variablen und Volumes.
• Projekte mit schnellem HTTPS ohne DNS-Änderungen: neo domain --temp für sofortige HTTPS-URL zum Testen mit sslip.io, später auf echte Domain umstellen.
• Zero-Downtime-Releases für kleine Teams: Blue-Green-Updates mit Health Checks, alte Version bleibt online bis neue Container bereit sind.

FAQ

• Installiert Neo einen Agenten auf meinem Server? Nein. Neo läuft auf Ihrem lokalen Rechner und verbindet sich per SSH mit Ihrem VPS. Auf dem Server werden nur Docker und Caddy für die App-Runtime eingerichtet.

• Ich nutze bereits docker-compose. Wie wechsle ich zu Neo? Führen Sie neo config generate im Projektverzeichnis aus. Neo scannt docker-compose.yml und erzeugt automatisch .neo.yml, dann können Sie neo deploy für den App-Versand nutzen.

• Welche Cloud-Provider werden unterstützt? Neo kann auf jeden SSH-fähigen VPS deployen, z. B. DigitalOcean, Hetzner, Linode, Vultr, AWS EC2, GCP und Azure. Neo deployt auf eine einzelne VM (kein Multi-Node-Cluster-Orchestrator wie Kubernetes oder Docker Swarm).

• Wie funktioniert HTTPS? Neo unterstützt neo domain --temp für sofortiges HTTPS via sslip.io, neo domain app example.com für Let’s Encrypt Auto-SSL nach DNS-Weiterleitung und --cert/--key für eigene Zertifikate.

• Kann Neo Background-Worker und Datenbanken ausführen? Worker lassen sich in .neo.yml deklarieren und werden als separate Container mit gleichem Image, Env-Vars und Volumes deployt. Für Datenbanken läuft Neo sie als Docker-Sidecars/Services bei kleineren Projekten; für Produktion mit Echt-Nutzern empfiehlt es managed Databases.

Alternativen

• Manuelle Docker + Caddy-Deploy-Skripte: Bei Vorliebe für volle Kontrolle und eigener Automatisierung bauen Sie Images, starten Container und managen Caddy/SSL selbst. Das erfordert meist mehr Aufwand als Neos One-Command-Workflow.
• Docker Swarm oder Kubernetes: Cluster-Orchestratoren für Multi-Node-Deployments. Sie unterscheiden sich von Neo durch Fokus auf Cluster-Orchestrierung statt einzelnem SSH-fähigem VPS.
• Andere VPS-zentrierte CI/CD-Pipelines: Generische CI/CD-Tools können per SSH Images bauen und Container restarten. Im Vergleich zu Neo managen Sie Config-Generierung, Zero-Downtime-Logik und HTTPS-Integration selbst.
• Managed Container-Plattformen: Plattformen mit Routing- und TLS-Management sparen Infra-Schritte. Sie opfern meist das SSH-first, „kein Agent/Control-Plane“-Deploy-Modell von Neo.