A private cloud doesn't stop at one datacenter.
Most organizations don't have one environment. They have a datacenter in production and one for redundancy, or their own hardware plus something in the cloud, or regulated data that can't leave the building while the rest is happy to scale elsewhere. The usual vendor answer is one installation per site — then you stitch together access, networking, and permissions between the islands yourself. Stackship does the opposite: the environment is the unit, not the cluster.
Your environment spans the clusters
An environment in Stackship owns its resources, its members, its permissions, and its network policy. Roughly like a subscription with a cloud provider, with one decisive difference: it isn't locked to a cluster or a region.
The same environment can be projected into several clusters and remain one environment. Isolation from other environments holds at every level — access, network, and resources — even when they share the same physical cluster.
That is the difference from managing several clusters in a list. The boundary goes around you, not around the cluster.
One boundary for access, network and resources — however many clusters it spans.
The clusters connect outward
Connect your cluster without opening a single inbound port.
A cluster joins with a one-time key. An agent inside the cluster connects outward to the control plane. No inbound firewall rules need to be negotiated, which is the difference between a project and an afternoon at an on-prem site.
No standing keys to your API server are stored in the platform. When an operator does something in a cluster, the operator's own identity travels along, so your own Kubernetes audit log shows who did what — not just that the platform did something. An agent can be blocked immediately.
Your cluster
agentA one-time key in — no inbound ports opened.
The same address in every environment
Crosslink lets an app in one cluster reach a database or service in another, at exactly the same address as if they stood side by side.
The app calls the address it has always used. If the target lives in another cluster, the call is carried there over an outbound mTLS connection. If it lives in the same cluster, the traffic never leaves it. The app configuration never changes: what is a single-cluster setup in development becomes several clusters in production without changing a line.
Everything that is a service works — apps, databases, queues, secret vaults, even services from third-party operators you run yourself.
Crosslink is enabled per environment and you choose the hub among your own clusters. A resource is shared with a flag. Nothing is provisioned before someone asks for it.
Development — one cluster
db-rw.prod.svc.cluster.localProduction — several clusters
db-rw.prod.svc.cluster.localThe same address in both. The app config never changes.
The boundary goes around you, not the cluster
Cluster B
your second datacenter
db-rw.prod.svc.cluster.localstand-in service — forwards the call
Cluster A
your hub
db-rw.prod.svc.cluster.localthe database — the real oneThree situations
Redundancy across two datacenters
One environment spans both sites. An app in one reaches the database or the queue in the other as if they were neighbors. On-prem multi-DC is the primary target — the design choices were made for organizations with their own datacenters, not cloud-first.
Data in one place, compute in another
Regulated or heavy data stays in its cluster. Stateless apps live in cheaper capacity that can scale freely. The data never moves; the apps come to it. For an organization that can't put its data in public cloud, this is the difference between forgoing the cloud and using it for the part that is allowed.
On-prem meets cloud
Your own clusters in-house plus one in the cloud look like one network. The same app configuration in every environment.
Traffic never passes through us
Stackship operates no relay nodes for customer traffic. That is a permanent design decision, not a limitation we hope to grow out of.
The hub is always a cluster you control, for the simple reason that whoever operates the hub can technically see the traffic. If you want confidentiality all the way, let the application's own encryption pass through untouched.
That is the sharpest difference from cloud providers' interconnect services, where the interconnection is something you buy and they operate.
Frequently Asked Questions
The network, the hub, and joining in practice.
Compliance
GDPR data residency, NIS2 controls, audit logging, policy as code, RBAC, and encryption. Built into the platform, on infrastructure you control.
Your database in one datacenter. Your app in the other.
Neither of them notices, and neither of them had to open a port. Tell us what your sites look like and we'll walk through how one environment would span them.
Book a walkthrough