OpenKubes logo

OpenKubes Kubernetes Platform Distribution Framework

OpenKubes is a framework for building sovereign Kubernetes platform distributions — built ADR-first, reviewed three ways, run on infrastructure you control.

OpenKubes defines the framework. OKP proves it can run. OpenKubes Platform (OKP) is its official reference distribution — deploy it as provided, adapt it, or use OpenKubes to build your own OpenKubes-conformant distribution.

View on GitHub Contribute
Explore

Explore the OpenKubes Universe

Two illustrated journeys make the ideas behind OpenKubes tangible — from the foundations of platform engineering to AI-assisted, verifiable operations.

Illustrated origin story

Meet Oki

Discover platform engineering through an illustrated story about clusters, contracts and trust.

Explore Oki Universe →
Illustrated guide for CIOs & SREs

Meet Aia

See how AI, Crossplane, Cluster API and robotics turn intent into a verifiable platform.

Explore Aia →
What it is

A contract-first platform engineering framework

OpenKubes formalizes how Kubernetes capabilities get built, provisioned, and verified — without locking teams into a single vendor, cloud, or component. Every capability follows the same chain from idea to running cluster:

Capability → Contract → Implementation Profile → Provider Values → Contract Tests

"A cluster is not considered fully provisioned until the contract test passes." — ADR-018

"No structure without a forcing consumer." A contract is only formalized once a second real consumer needs it.

Decisions are recorded as Architecture Decision Records (ADRs) and never skipped — there is no implementation without a committed ADR. The project's knowledge graph (okgraph.py) maps every ADR, commit, and issue into a single traversable structure, so the reasoning behind the platform is never lost.

How decisions get made

Three-way review, human merge

Every ADR passes through a structured review before it can be merged:

Author

Anyone — maintainer or external contributor — can author an ADR or propose a change on a branch. No direct write access to main.

Claude & GPT review

Claude checks internal consistency and missing counter-arguments. GPT checks governance language and cross-ADR consistency. AI may argue — it does not merge.

Human merge

The maintainer holds project context and makes the final call. "AI may argue; only humans merge."

Branch protection is enforced on the mother repo: pull requests required, no force-push, linear history. The three-way review is a process discipline, not a technical gate.

Writing

From the field

Essays and stories on how OpenKubes is built — the method, the contracts, and what happened when we let AI agents work inside them.

The Secret Contract, Made Real

Where do secrets live, and how does a workload three clusters away get exactly the one it needs — and nothing more? How OpenKubes turns the Secret Contract into a datacenter profile: a central Vault consumed through the Vault Secrets Operator, onboarded declaratively with Crossplane.

The Contract Is the Guardrail

An AI agent fixed a crashing deployment, found two bugs in its own test, and declined a change that crossed an ownership boundary — none of it requiring trust in the model. How deterministic sensors and a human-controlled gate make AI-assisted platform work safe and productive.

The Immortal Platform

Building self-healing digital infrastructure with OpenKubes — what happens when the infrastructure that runs Kubernetes itself fails.

Kubernetes Anywhere. Make it.

How we built OpenKubes with Crossplane and Cluster API — from the second cluster problem to a contract-first framework.

Where the code lives

Repositories

All repos are public — code, contracts, and ADRs are open. Real provider values and cluster credentials never live in the repos; reaching a live cluster itself requires VPN access.

Get involved

How to contribute

  1. Read the method first. Start with docs/platform-engineering-method.md in openkubes/openkubes and browse the ADR series to understand what's already decided.
  2. Find a forcing consumer. OpenKubes doesn't build structure speculatively — proposals land better when tied to a real second use case, not a hypothetical one.
  3. Open a branch, not a direct commit. main is protected. Author your ADR or change on a branch and open a pull request.
  4. Go through three-way review. Expect feedback from both AI reviewers before a maintainer makes the merge decision.
  5. Small, scoped changes. ADRs are precise and narrow — future ideas become new tickets rather than expanding an in-flight one.

Good places to start

Constrained edge profile

Five open spikes: OS candidate, GitOps agent, image strategy, storage, autonomy-under-partition.

ok CLI

Wrapper-vs-logic-carrier design spike — standalone binary vs. kubectl plugin (Krew).

Requirements inventory

Research spike on whether a first-class Requirement layer belongs in the architecture.

Cluster deregistration

make unregister-cluster — clean up orphaned secrets and ProviderConfigs after teardown.

Community

Launch meetup & contact

🚀 OpenKubes Launch Meetup — Thu, Aug 6, 2026, 7:00 PM, online via Zoom. Hosted by Kubernauts Worldwide Meetup. Agenda: why OpenKubes, project vision, a live demo of declarative cluster provisioning with private AI, roadmap, and how to become a contributor.

Register for the Launch Meetup
GitHub Issues Slack kubernauts.io