Hoe we Tradevo’s deploy-flow bouwden

Twee jaar geleden deployden we een klantsite als volgt: laptop open, ssh, git pull, pnpm install, pnpm build, pm2 restart, soms handmatig nginx reload, vingers kruisen. Per site ongeveer een halve middag. Met twintig sites werd dat oneconomisch.

Tradevo.nl is onze interne oplossing: geen Kubernetes, geen Docker Swarm, geen fancy orchestrator. Wel een platte set TypeScript-scripts, een JSON-poort-registry, systemd-templates en een dun web-dashboard. Elk onderdeel bestaat omdat we er tegenaan liepen.

De poort-registry is het hart. Elke klantsite krijgt één poort tussen 3000 en 3099. Geen botsingen meer. Een Node-script leest de registry, genereert een systemd-service-file per klant, en een bijbehorende nginx-vhost. Deploy = tar + scp + extract + install + build + systemctl restart. Vijf minuten.

De lastigste puzzel was Let’s Encrypt automatisering. Certificaten die zonder waarschuwing aflopen zijn het meest banale faal-scenario op een VPS. We schreven een cron die 7 dagen voor expiratie renewt, failt over naar een webroot-challenge als DNS-01 niet werkt, en een Slack-webhook stuurt bij onverwachte exit-codes.

Een bonus: Cloudflare’s API. We automatiseren de A-record creatie bij nieuwe klanten, zetten hem initieel op grey-cloud voor cert-issuance, en flippen naar orange-cloud na validatie. Dat bespaart vijf minuten per site en voorkomt een klassieke Let’s-Encrypt-vs-Cloudflare-proxy-fout die makkelijk te maken is.

Open-sourcing van Tradevo is in discussie. De huidige codebase is sterk gekoppeld aan onze VPS-setup (Ubuntu 24 + nginx + systemd), maar een abstracted variant lijkt bruikbaar voor studios met 10-30 klantsites. Als je interesse hebt: [email protected].