Run at the edge, without opening a door into your platform.
Deploy into edge locations you don’t fully control (retail sites, factory floors, partner data centers, remote racks) with hard security boundaries that protect their network and yours, built on a default-deny overlay where nothing crosses until you say so.
Compute at the edge, isolation by default.
Running close to where things happen (a store, a plant, a partner’s premises, a remote site) is increasingly where the value is. But every place you put compute is a new attachment point. Done wrong, an edge site becomes a path into the rest of your platform, or your platform becomes a risk to the site’s own network.
ZeusK8s treats every edge location as its own isolated zone. By default nothing crosses the boundary: the edge can’t reach into your core, and your core can’t expose the edge’s network. You then approve exactly the flows that should exist, and nothing else. The result is compute wherever you need it, with a security posture you can actually explain to a security team or an auditor.
From zero to running.
Place a cluster at the edge
Stand up a cluster on whatever hardware lives at the site (a small box at a store, a server in a plant, a rack at a partner DC) through the same workflow you use for cloud.
It’s isolated by default
Each edge site is its own zone with default-deny networking. Out of the box it can’t reach your core platform, and your platform can’t reach into its local network.
Approve only the flows that should exist
Open precisely the connections the workload needs, this cluster to that one, optionally limited to ports, and nothing more. Grants are explicit and directional, not IP-guesswork.
Prove the boundary
The connectivity map shows every grant that exists, and a drawn arrow is an enforced grant. The isolation isn’t a promise in a doc; it’s exactly what’s on the map.
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.
Questions you’d actually ask.
What kind of “edge” does this cover?
Anywhere outside your core cloud that you don’t fully trust or control: retail and branch sites, factory and warehouse floors, partner or customer premises, remote field deployments, and on-prem racks. If you’re putting compute somewhere new, it’s an edge zone.
How is the boundary actually enforced?
Every cluster sits on an encrypted overlay that’s default-deny: a fresh edge zone can reach nothing and is reachable by nothing. Only the directional grants you explicitly approve can cross, and the connectivity map is the source of truth for what’s allowed.
Does the edge site need an open inbound port?
No. The edge dials out over an encrypted tunnel, so there’s nothing inbound to expose. That’s a big part of why it’s safe to place compute somewhere you don’t own the firewall.
What if the edge site loses connectivity?
The local cluster keeps running. It’s a real, independent Kubernetes cluster, not a thin remote node, so the workload survives a link outage and reconciles when the connection returns.
Can the edge still use my global data and services?
Yes, selectively. You approve which core services or data an edge zone may reach, so it gets exactly what it needs (and nothing it doesn’t) over the same secured boundary.
Keep exploring.
All features →Identity, policy, and compliance controls.
Explore →The encrypted overlay the boundaries are built on.
Explore →Run on your own hardware anywhere.
Explore →Start running it today.
Spin up your first cluster free, or get a guided tour from our team.