ZeusK8s
Environment management

Config drift is how “it worked in staging” becomes a 2am outage.

Config drift — a value different in prod than staging, a secret updated in one place and not another — is behind most outages nobody can explain. ZeusK8s manages configuration in layers so there's one truth, not 23 YAML files slowly diverging.

The end of “it worked in staging.”

Most outages trace back to configuration drift: a value that's different in prod than staging, a secret that was updated in one place and not another, a copy of a YAML file that no one remembers forking. As you add clusters and teams, the copies multiply and the truth gets lost.

ZeusK8s manages configuration as layers (shared defaults, per-environment overrides, per-cluster specifics) composed at deploy time. Change a value once and it applies everywhere it should. Compare environments side by side to see exactly what differs, instead of diffing giant files by eye.

Zeus · Environments
Environment config
Layered, composed at deploy. One source of truth.
defaults LOG_LEVEL · CACHE_TTL · REGION_MODE
staging replicas: 2 · tag: rc
prod replicas: 10 · tag: v1.8
staging → prod · what differs
replicas 2 10
image tag rc v1.8
memory 512Mi 2Gi
How it works

From zero to running.

01

Define shared defaults

Set the configuration that’s common across everything once. It becomes the baseline every environment inherits.

02

Layer per-environment overrides

Override only what actually differs in dev, staging, or prod (replicas, image tags, resource sizes) explicitly, not as a forked copy.

03

Compose per cluster

When an environment spans clusters or clouds, per-cluster specifics layer on top. Run 10 replicas in us-east and 3 in europe from the same definition.

04

Compare and deploy

See exactly what differs between environments before you ship, then deploy with the composed values applied automatically.

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.

Model
Layered config: defaults → environment → cluster
Overrides
Replicas, image tags, resources, ports, env vars
Secrets
Pulled from the encrypted Connections store at deploy
Env files
Layer .env-style files; merged in order
Comparison
Side-by-side environment diffs
Namespaces
Per-environment namespaces created and managed
Straight answers

Questions you’d actually ask.

How is this different from values.yaml files?

Values files are static copies you keep in sync by hand. Zeus composes layers at deploy time from one source of truth, so a change propagates everywhere it should and you can see exactly what differs between environments.

Where do environment secrets come from?

From Connections, the encrypted credential store. Services reference a secret by name and it’s injected at deploy. It never lives in the environment config in plaintext.

Can one environment span multiple clusters?

Yes. An environment can deploy to several clusters across clouds, with per-cluster overrides layered on top of the shared definition.