Positioning

This page is the one-picture explanation of where plexsphere sits in the stack. It is the engineering-facing companion to the visualization on the public landing page: same three-layer story, same vocabulary, rendered inline so the docs and the marketing page never drift.

For the technical architecture — the two-binary control-plane runtime, shared platform packages, trust model — see Architecture overview. For the dashboard, the storage topology, and the signed-event-bus roadmap, see the other pages in this section.

The picture

Three layers, one direction of dependency. The middle layer is the product.

Your ecosystemthe services you build

AppsDatabasesAI workloadsPartner APIsInternal toolsAutomation

↓ one identity · one network · one policy · one provisioning

◆plexspherethe sovereign control plane

IdentityOIDC federation · ReBAC · per-Domain trust

NetworkEncrypted WireGuard mesh across providers

PolicyL3/L4 rules · signed events · per-node enforcement

SecretsOpenBao-backed · NSK-wrapped · no plaintext on nodes

Mediated accessSSH · kubectl · TCP · JWT-bounded, audited

ProvisioningKRM / Crossplane Blueprints, portable across clouds

↓ any substrate · any provider · no lock-in

Any substrateedge to cloud, sovereign or hyperscale

AWSGCPAzureHetznerOpenStackBare-metalKubernetesEdge / NAT

Hyperscaler Sovereign cloud Your hardware / edge Any tier, anywhere

How to read it

• Top layer — your ecosystem. Anything you build on top of the control plane: applications, databases, AI workloads, partner integrations, internal tools, automation. Services target plexsphere; they do not target AWS, GCP, OpenStack, or a specific Kubernetes distribution.
• Middle layer — plexsphere. A single coherent surface for the six capabilities every distributed service needs from its substrate. Each capability is named in the Key Capabilities section of the root README and detailed in the corresponding bounded context. The middle layer is the only one with the accent treatment because it is the only one the project itself ships.
• Bottom layer — any substrate. The clouds, the sovereign clouds, the bare-metal racks, the Kubernetes clusters and the NAT-bound edge nodes that plexsphere reconciles. The colour coding distinguishes hyperscalers from sovereign clouds and from operator-owned substrate, because the choice between them is a policy and procurement decision plexsphere preserves rather than forecloses.

The single direction of dependency is the load-bearing claim: an ecosystem service only depends on plexsphere, and plexsphere only depends on the substrate's portable surface (KRM via Crossplane for provisioning, OIDC for identity, WireGuard for the data plane). Substituting the substrate underneath is a configuration change, not a codebase change.

Where this story is enforced in the code

The picture is not a marketing artifact — it is the shape of the codebase. The middle layer maps to the bounded contexts under internal/:

Capability	Primary context(s)	Read more
Identity	internal/identity (+ federated OIDC bindings)	Access model in the README
Network	internal/mesh	Mesh roadmap
Policy	internal/policy (+ internal/signing for events)	README — Policy Engine
Secrets	internal/secrets (+ OpenBao adapter)	README — Secret Management
Mediated access	internal/access	README — Access Orchestration
Provisioning	internal/provisioning (+ Crossplane management fleet)	README — Resource Provisioning

The same vocabulary — identity, network, policy, secrets, mediated access, provisioning — appears in the landing page diagram, in this docs diagram, and in the package names under internal/. When you change a capability in one place, change it everywhere; the ubiquitous language is the contract.

When to use which diagram

• Landing page (contrib/main/index.html § In one picture) — for first-contact audiences: investors, partners, operators evaluating the product. Stylised, accent-heavy, no jargon outside the chip labels.
• This page — for engineers reading the docs after the pitch. Same story, but with the implementation seams and the link out to the bounded contexts that own each capability.
• Architecture overview — for contributors who need the runtime topology, the two-binary control-plane split, and the trust model. One level deeper than this page.