The Six-Plane Architecture

DevPortal organizes every infrastructure capability into six distinct planes. Each plane owns a clear vertical of concern. Planes communicate through a typed event bus, not direct coupling, which means you can adopt them incrementally.

The six planes at a glance

Why planes?

Traditional internal developer platforms grow into monoliths because every new capability gets bolted onto an existing abstraction. DevPortal's plane model enforces a single rule: cross-plane communication is always asynchronous and mediated by a typed event.

This has three practical consequences:

1. Independent evolution — the security plane can be upgraded without restarting the compute plane.
2. Per-plane policy — each plane has its own admission controller, so a misconfigured storage policy cannot affect network behaviour.
3. Observability locality — each plane emits its own telemetry, reducing the blast radius of a tracing misconfiguration to a single plane.

The Control Plane in depth

Responsibilities

The Control Plane is the only plane allowed to issue commands to other planes. It exposes three primary interfaces:

• Declarative API (devportal.io/v1) — Kubernetes-native CRDs for Services, Pipelines, Policies, and Environments.
• GitOps engine — watches Git repositories and reconciles desired state against the live cluster state.
• Agent runtime — hosts AI agents that analyse telemetry, propose runbooks, and execute approved remediation actions.

Reconciliation loop

Git commit
    │
    ▼
Source Controller (reads Git)
    │
    ▼
Policy Admission (OPA checks)
    │  pass / reject
    ▼
Diff Engine (desired vs actual)
    │
    ▼
Plane Dispatcher (fanout to planes)
    │
    ├── Compute Plane
    ├── Storage Plane
    └── Network Plane

Plane interaction model

Planes interact through events on the internal bus. An event has the shape:

Consumers subscribe using a declarative filter:

apiVersion: devportal.io/v1
kind: EventSubscription
metadata:
  name: alert-on-security-violation
spec:
  filter:
    plane: security
    kind: policy.violation
  handler:
    type: webhook
    url: https://hooks.slack.com/...

Adopting planes incrementally

You do not need to adopt all six planes at once. A typical adoption path looks like:

Phase 1 — Control + Compute

Start with declarative service definitions and basic GitOps. Skip the other planes; DevPortal defaults to Kubernetes-native behaviour.

Phase 2 — Observability

Attach the observability plane to get unified metrics and traces. No changes to existing workloads are required — the plane uses opentelemetry-operator to auto-instrument running pods.

Phase 3 — Security

Enable the security plane to enforce RBAC and OPA policies. Start in audit mode (log violations, do not block) before switching to enforce.

Phase 4 — Storage + Network

Round out the platform with advanced storage lifecycle management and zero-trust networking via Cilium.

Further reading

• Agent Runtime — how AI agents reason across planes
• Policy Engine — OPA + Casbin integration in depth
• Observability Plane — telemetry pipeline reference