ZeusK8s
Builds & CI

One builder per build. No queues, no blocked teams, no QEMU.

Zeus runs dedicated build machines — on AWS, GCP, or your own hardware — one per concurrent build. The API build isn't waiting behind the frontend. ARM64 isn't waiting behind x86. Builds that used to block each other don't anymore.

Build infrastructure that matches how you actually ship.

Most CI systems give you a shared queue and call it a day. If your frontend build takes 12 minutes and your API needs to go out, it waits. Zeus gives you dedicated builders — one per concurrent build — so fast things don't wait for slow things and no single repo can starve the rest of your team.

Zeus builds natively for amd64 and arm64 in parallel on real hardware — not QEMU emulation. The same commit produces both architectures at once, at native speed. Built images go straight to Harbor for vulnerability scanning before any deploy is possible. From there, one action ships to a single cluster or every cluster you run.

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

Connect GitHub

OAuth link to your repos. Zeus watches branches and builds on push. Tag conventions and pull secrets are handled automatically — nothing to configure per cluster.

02

Builders run in parallel

amd64 and arm64 build simultaneously on native hardware. Multiple services build at the same time — each on its own builder. No queue, no waiting for a slow build to free a runner.

03

Push to Harbor, scan with Trivy

Built images land in Harbor. Trivy vulnerability scans run automatically. An image that hasn't been scanned can't be promoted to production — the gate is enforced, not optional.

04

Promote and deploy globally

A scanned, tagged image can go to one environment or every cluster you run — EKS, GKE, k3s — in a single action. Watch the rollout live per 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 — watches branches, builds on push
Architectures
amd64 + arm64 built simultaneously on native hardware, no QEMU
Builders
Dedicated per-service or shared pool; one build per builder
Compute
Spot instances by default with self-healing; dedicated persistent volume per builder survives instance replacement
Where
AWS, GCP, or your own Proxmox hardware
Registry
Harbor — Trivy scanning, RBAC, replication, proxy-cache
Pull secrets
Injected per cluster automatically
Tagging
Consistent, traceable image tags per build
Straight answers

Questions you’d actually ask.

How many builds can run at once?

One per builder. Add a builder per service you want to keep unblocked, or run a shared pool. It's a simple model: more builders = more parallelism, with no queue configuration needed.

What happens if a spot instance is terminated mid-build?

Each builder has dedicated persistent storage that stays mounted across instances. When a spot is reclaimed, Zeus brings up a new instance and attaches the same volume — the build resumes from its cache rather than starting from scratch. You don't lose the layer cache, the intermediate artifacts, or the time already spent. Spot is the default precisely because the recovery is built in.

Is ARM64 actually native or just QEMU?

Native. Zeus provisions real arm64 instances — Graviton on AWS, Tau T2A on GCP, or your own arm64 Proxmox nodes — and builds directly on them. QEMU emulation is 4-10x slower and produces subtly different binaries. We don't use it.

Can I use my own hardware for builds?

Yes. If you're running Proxmox, Zeus can run builders on your own nodes at zero cloud compute cost. Switch to AWS or GCP builders for capacity bursts, or run a mix.

Does this replace GitHub Actions?

For the build-image-and-deploy path, yes. If you have test suites in Actions you want to keep, Zeus can consume the images they produce instead. Either way, multi-arch builds, Harbor scanning, and multi-cluster deploy come from one place.

What if an image has vulnerabilities?

Trivy flags it and the image is blocked from promotion. You see the CVEs in Zeus before anything reaches a cluster. You can configure severity thresholds — block on Critical only, or block on any High+.