ZeusK8s
Builds & CI

Ein Builder pro Build. Keine Queues, keine blockierten Teams, kein QEMU.

Zeus betreibt dedizierte Build-Maschinen — auf AWS, GCP oder Ihrer eigenen Hardware — eine pro concurrent Build. Der API-Build wartet nicht hinter dem Frontend. ARM64 wartet nicht hinter x86. Builds, die sich früher gegenseitig blockierten, tun das nicht mehr.

Build-Infrastruktur, die zu dem passt, wie Sie tatsächlich shippen.

Die meisten CI-Systeme geben Ihnen eine shared Queue und nennen es einen Tag. Wenn Ihr Frontend-Build 12 Minuten dauert und die API raus muss, wartet sie. Zeus gibt Ihnen dedizierte Builder — eine pro concurrent Build —, damit schnelle Dinge nicht auf langsame warten und kein einzelnes Repo den Rest Ihres Teams aushungern kann.

Zeus baut nativ für amd64 und arm64 parallel auf echter Hardware — nicht QEMU-Emulation. Derselbe Commit produziert beide Architectures gleichzeitig, mit nativer Speed. Gebaute Images gehen direkt nach Harbor für Vulnerability Scanning, bevor ein Deploy möglich ist. Von dort shippt eine Aktion auf einen einzelnen Cluster oder jeden Cluster, den Sie betreiben.

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

GitHub verbinden

OAuth-Link zu Ihren Repos. Zeus watched Branches und baut on Push. Tag Conventions und Pull Secrets werden automatisch gehandhabt — nichts pro Cluster zu konfigurieren.

02

Builder laufen parallel

amd64 und arm64 bauen gleichzeitig auf nativer Hardware. Mehrere Services bauen zur selben Zeit — jeder auf dem eigenen Builder. Keine Queue, kein Warten auf einen langsamen Build, bis ein Runner frei wird.

03

Nach Harbor pushen, mit Trivy scannen

Gebaute Images landen in Harbor. Trivy Vulnerability Scans laufen automatisch. Ein Image, das nicht gescannt wurde, kann nicht nach Production promoted werden — das Gate ist enforced, nicht optional.

04

Promoten und global deployen

Ein gescanntes, getaggtes Image kann in einer Aktion auf ein Environment oder jeden Cluster gehen, den Sie betreiben — EKS, GKE, k3s. Rollout live pro Cluster beobachten.

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 — watched Branches, baut on Push
Architectures
amd64 + arm64 gleichzeitig auf nativer Hardware gebaut, kein QEMU
Builder
Dediziert per-Service oder shared Pool; ein Build pro Builder
Compute
Spot-Instanzen by Default mit Self-Healing; dediziertes persistentes Volume pro Builder überlebt Instance Replacement
Where
AWS, GCP oder Ihre eigene Proxmox-Hardware
Registry
Harbor — Trivy Scanning, RBAC, Replikation, Proxy-Cache
Pull Secrets
Pro Cluster automatisch injiziert
Tagging
Konsistente, traceable Image Tags pro Build
Straight answers

Questions you’d actually ask.

Wie viele Builds können gleichzeitig laufen?

Einer pro Builder. Einen Builder pro Service hinzufügen, den Sie unblocked halten wollen, oder einen shared Pool betreiben. Einfaches Modell: mehr Builder = mehr Parallelität, ohne Queue-Konfiguration.

Was passiert, wenn eine Spot-Instanz mitten im Build terminated wird?

Jeder Builder hat dedizierten persistenten Storage, der über Instanzen gemountet bleibt. Wird ein Spot reclaimed, bringt Zeus eine neue Instanz hoch und attacht dasselbe Volume — der Build setzt vom Cache fort, statt von scratch zu starten. Sie verlieren weder Layer Cache noch Intermediate Artifacts noch die bereits investierte Zeit. Spot ist Default genau deshalb, weil Recovery integriert ist.

Ist ARM64 wirklich native oder nur QEMU?

Native. Zeus provisioniert echte arm64-Instanzen — Graviton auf AWS, Tau T2A auf GCP oder Ihre eigenen arm64-Proxmox-Nodes — und baut direkt darauf. QEMU-Emulation ist 4–10× langsamer und produziert subtil andere Binaries. Wir nutzen es nicht.

Kann ich eigene Hardware für Builds nutzen?

Ja. Wenn Sie Proxmox betreiben, kann Zeus Builder auf Ihren eigenen Nodes zu null Cloud-Compute-Kosten laufen lassen. Für Capacity Bursts auf AWS- oder GCP-Builder wechseln oder einen Mix betreiben.

Ersetzt das GitHub Actions?

Für den Build-Image-and-Deploy-Pfad ja. Wenn Sie Test Suites in Actions behalten wollen, kann Zeus die Images konsumieren, die sie produzieren. So oder so: Multi-Arch Builds, Harbor Scanning und Multi-Cluster Deploy kommen aus einem Ort.

Was, wenn ein Image Vulnerabilities hat?

Trivy flaggt es und das Image ist von Promotion geblockt. Sie sehen die CVEs in Zeus, bevor etwas einen Cluster erreicht. Severity Thresholds konfigurierbar — nur Critical blocken oder ab High+.