Wie wir Tradevos Deploy-Flow gebaut haben

Vor zwei Jahren deployten wir eine Kundensite so: Laptop auf, ssh, git pull, pnpm install, pnpm build, pm2 restart, manchmal manuell nginx reload, Daumen drücken. Pro Site ungefähr einen halben Nachmittag. Bei zwanzig Sites wurde das unwirtschaftlich.

Tradevo.nl ist unsere interne Lösung: kein Kubernetes, kein Docker Swarm, kein schicker Orchestrator. Stattdessen ein flacher Satz TypeScript-Skripte, eine JSON-Port-Registry, systemd-Templates und ein schlankes Web-Dashboard. Jeder Teil existiert, weil wir gegen das Problem gelaufen sind.

Die Port-Registry ist das Herzstück. Jede Kundensite bekommt einen Port zwischen 3000 und 3099. Keine Kollisionen mehr. Ein Node-Skript liest die Registry, generiert eine systemd-Service-Datei pro Kunde und einen passenden nginx-vhost. Deploy = tar + scp + extract + install + build + systemctl restart. Fünf Minuten.

Das kniffligste Puzzle war die Let's-Encrypt-Automatisierung. Zertifikate, die ohne Warnung ablaufen, sind das banalste Fehlerszenario auf einem VPS. Wir schrieben einen Cron, der 7 Tage vor Ablauf erneuert, auf eine webroot-Challenge ausweicht, wenn DNS-01 nicht funktioniert, und bei unerwarteten Exit-Codes einen Slack-Webhook schickt.

Ein Bonus: Cloudflares API. Wir automatisieren das Anlegen des A-Records bei neuen Kunden, setzen ihn anfangs auf Grey-Cloud für die Zertifikats-Ausstellung und schalten nach der Validierung auf Orange-Cloud um. Das spart fünf Minuten pro Site und verhindert einen klassischen Let's-Encrypt-gegen-Cloudflare-Proxy-Fehler, der leicht passiert.

Das Open-Sourcing von Tradevo steht zur Diskussion. Die aktuelle Codebasis ist stark an unser VPS-Setup gekoppelt (Ubuntu 24 + nginx + systemd), aber eine abstrahierte Variante scheint für Studios mit 10-30 Kundensites brauchbar. Bei Interesse: [email protected].