ZeusK8s
Builds & CI

Un builder par build. Pas de files d'attente, pas d'équipes bloquées, pas de QEMU.

Zeus exécute des machines de build dédiées — sur AWS, GCP ou votre propre matériel — une par build concurrent. Le build API n'attend pas derrière le frontend. ARM64 n'attend pas derrière x86. Les builds qui se bloquaient mutuellement ne le font plus.

Une infra de build qui correspond à la façon dont vous shippez vraiment.

La plupart des systèmes CI vous donnent une file partagée et s'arrêtent là. Si votre build frontend prend 12 minutes et que votre API doit sortir, elle attend. Zeus vous donne des builders dédiés — un par build concurrent — pour que les choses rapides n'attendent pas les lentes et qu'aucun repo unique ne puisse affamer le reste de l'équipe.

Zeus build nativement pour amd64 et arm64 en parallèle sur du vrai hardware — pas d'émulation QEMU. Le même commit produit les deux architectures à la fois, à vitesse native. Les images atterrissent directement dans Harbor pour un scan de vulnérabilités avant tout déploiement possible. De là, une action shippe vers un seul cluster ou tous ceux que vous opérez.

Zeus · Builds
Image builds
Connected to GitHub · builds on every push · native arm64
Live
RepoBranch / CommitArchDurationStatus
api-gatewaya3f12c9 mainamd64 · arm641m 14sPushed · 2m
web-client7d4e1b0 mainamd64
62%
Building · now
worker9c1a55f mainarm640m 58sPushed · 14m
auth-serviceb2e8d31 mainamd64 · arm641m 22sPushed · 31m
report-exporterc9f1a44 mainamd640m 33sFailed · 48m
image-processord7b3e10 releaseamd64 · arm642m 01sPushed · 1h
schedulere4c2f88 mainamd640m 47sPushed · 2h
web-client · live build output building
#1 [internal] load build definition from Dockerfile
#1 sha256:a2f… 0.0s done
#2 [internal] load .dockerignore
#2 transferring context: 34B done
#3 [internal] load metadata for node:20-alpine
Each image links to the services that use it — deploy to any cluster in a click.
How it works

From zero to running.

01

Connectez GitHub

Lien OAuth vers vos repos. Zeus surveille les branches et build au push. Conventions de tags et pull secrets sont gérés automatiquement — rien à configurer par cluster.

02

Les builders tournent en parallèle

amd64 et arm64 buildent simultanément sur du hardware natif. Plusieurs services buildent en même temps — chacun sur son propre builder. Pas de file, pas d'attente qu'un build lent libère un runner.

03

Push vers Harbor, scan avec Trivy

Les images atterrissent dans Harbor. Les scans de vulnérabilités Trivy tournent automatiquement. Une image non scannée ne peut pas être promue en production — le gate est appliqué, pas optionnel.

04

Promouvez et déployez globalement

Une image scannée et taguée peut aller vers un environnement ou tous les clusters que vous opérez — EKS, GKE, k3s — en une seule action. Regardez le rollout en live par cluster.

The specifics

Built by people who run this in production.

No hand-waving. Here’s what’s actually under the hood: the kind of detail you’d expect from a platform you’re going to trust with production.

Sources
GitHub OAuth — surveille les branches, build au push
Architectures
amd64 + arm64 buildés simultanément sur hardware natif, sans QEMU
Builders
Dédiés par service ou pool partagé ; un build par builder
Compute
Instances spot par défaut avec self-healing ; volume persistant dédié par builder survit au remplacement d'instance
AWS, GCP ou votre propre matériel Proxmox
Registry
Harbor — scan Trivy, RBAC, réplication, proxy-cache
Pull secrets
Injectés par cluster automatiquement
Tagging
Tags d'image cohérents et traçables par build
Straight answers

Questions you’d actually ask.

Combien de builds peuvent tourner en même temps ?

Un par builder. Ajoutez un builder par service que vous voulez garder débloqué, ou faites tourner un pool partagé. C'est un modèle simple : plus de builders = plus de parallélisme, sans configuration de file.

Que se passe-t-il si une instance spot est terminée en plein build ?

Chaque builder a un stockage persistant dédié qui reste monté entre instances. Quand un spot est repris, Zeus lève une nouvelle instance et attache le même volume — le build reprend depuis son cache plutôt que de repartir de zéro. Vous ne perdez ni le cache de layers, ni les artefacts intermédiaires, ni le temps déjà dépensé. Spot est le défaut précisément parce que la recovery est intégrée.

ARM64 est-il vraiment natif ou juste QEMU ?

Natif. Zeus provisionne de vraies instances arm64 — Graviton sur AWS, Tau T2A sur GCP, ou vos propres nœuds arm64 Proxmox — et build directement dessus. L'émulation QEMU est 4-10× plus lente et produit des binaires subtilement différents. Nous ne l'utilisons pas.

Puis-je utiliser mon propre matériel pour les builds ?

Oui. Si vous faites tourner Proxmox, Zeus peut exécuter des builders sur vos propres nœuds à coût compute cloud zéro. Passez à des builders AWS ou GCP pour des bursts de capacité, ou un mix.

Est-ce que ça remplace GitHub Actions ?

Pour le chemin build-image-and-deploy, oui. Si vous avez des suites de tests dans Actions que vous voulez garder, Zeus peut consommer les images qu'elles produisent à la place. Dans les deux cas, builds multi-arch, scan Harbor et déploiement multi-cluster viennent d'un seul endroit.

Et si une image a des vulnérabilités ?

Trivy la flague et l'image est bloquée à la promotion. Vous voyez les CVE dans Zeus avant que quoi que ce soit n'atteigne un cluster. Vous pouvez configurer des seuils de sévérité — bloquer uniquement sur Critical, ou bloquer sur tout High+.