GitOps.dk

Autonomous Platform Foundation

The core GitOps.dk architecture for a self-operating platform.

GitOps.dk

This is the architecture we reach for when an organisation says: we want a platform that runs itself, survives audits, and does not depend on the three people who built it. It is deliberately unexciting — every component earns its place by removing a class of human intervention.

Control plane and data plane

The foundation separates what decides from what runs. A small, hardened control plane holds the reconciliation engine, policy engine, secrets flow and registry. Data planes — the clusters where workloads live — are disposable by design: rebuilt from their declarations rather than repaired, because their entire identity is in Git.

  • Control plane: reconciliation, policy, identity, artefact registry, observability backends.
  • Data planes: workload clusters, rebuilt from declarations, never patched by hand.
  • The blast-radius rule: nothing on a data plane can break the control plane.
Reference architectureAutonomous platform foundation

Desired state

Git holds everything — including the platform's own components.

  • Applications
  • Infrastructure
  • Policy
  • Platform components
  • Environments
Continuously reconciled by

Control plane

Small, hardened; decides, never runs workloads.

  • Reconciliation engine
  • Policy engine
  • Identity
  • Secrets flow
  • Artefact registry
  • Observability backends
Converges live state on

Data planes

Disposable; rebuilt from their declarations, never patched by hand.

  • Workload cluster
  • Workload cluster
  • Workload cluster …
Experienced by product teams as

Golden paths

Service templates that arrive wired for day one.

  • Delivery
  • Observability
  • Security scanning
  • Cost attribution
  • Documentation

RuleNothing on a data plane can break the control plane. Emergency access exists behind glass, is audited, and is reconciled away afterwards.

Desired state in Git is reconciled by a small control plane onto disposable data planes; golden paths sit on top so a new service arrives production-wired.

The reconciliation core

Git holds desired state for everything — applications, infrastructure, policy, even the platform's own components. Controllers continuously converge live state toward it. This is the property that makes the platform autonomous rather than automated: automation executes scripts when asked; reconciliation closes gaps without being asked.

The golden paths layer

On top of the reconciliation core sit the paved roads: service templates that arrive wired for delivery, observability, security scanning and cost attribution on day one. A new service goes from 'idea' to 'running in production with dashboards' without a ticket — that is the layer product teams actually experience as the platform.

Observability and policy as load-bearing walls

Autonomy without observability is negligence. Every reconciliation, promotion and policy decision emits evidence: what changed, why, triggered by which commit. Policy is code, versioned beside what it governs — which turns audits from archaeology into a Git query.

“The measure of the foundation is not what it can do. It is what nobody has to do anymore.”

Turning these ideas into a platform?

For platforms where failure has consequences.

Start an Architecture Conversation