TRUKHIN #CloudRING Source on GitHub
Menu

How CloudRING is put together

CloudRING treats a cloud like an operating system. A shared core is meant to handle what every service needs, while the services themselves stay replaceable.

Three layers

Source: the README, “Target architecture”. This is the design the project is building toward, not a description of what runs today.

The target design separates three concerns:

  1. Provider management plane. Identity, tenancy, product governance, commercial policy, APIs, audit and fleet coordination.
  2. Regional cells. Bounded units of scale and failure, where lifecycle controllers and infrastructure bindings run.
  3. Product data planes. Services built on their own, whose heavy traffic and internals never pass through the platform core.
CloudRING target architecture Users, enterprises and agents reach one provider management plane through one API. The management plane coordinates two regional cells. Each cell runs services that service teams build against OCSv3. A dashed line marks future, opt-in federation with other providers. Independently operated provider Users and agents people, CLIs, automation Service teams build once against OCSv3 Provider management plane identity, tenancy, IAM, audit, catalogue, orders, quota, metering Regional cell A lifecycle controllers Regional cell B lifecycle controllers Services network, volumes, VMs Services Kubernetes, storage Other providers one API opt-in federation, after 1.0
Federation with other providers is opt-in and comes after 1.0.

Federation, when a provider opts in, must not add a shared root administrator, a universal database or a coordinator whose loss would take every provider down. If federation or management connectivity drops for a while, existing workloads should keep running, as far as a product’s operating model allows.

The shared core

Source: the README, “A cloud operating system, not a fixed service bundle”.

The core is meant to provide what shouldn’t be rebuilt for every service:

Compute, networks, volumes, Kubernetes, object storage, databases and future products are all services. A service can come from the CloudRING project, from a provider or from an independent team. What makes it first-class is meeting the same contracts as everyone else, with no privileged access to the platform’s internals.

The development installer

Sources: the development installation guide, the notes of release v0.1.0-c02.1 and roadmap goal G01.

The v0.1.0-c02.1 prerelease ships cloudring dev, which is built to create an empty CloudRING provider inside one new Linux VM. That VM runs upstream kubeadm Kubernetes, containerd, Cilium, PostgreSQL and the public API and portal server. The first supported substrate is an existing Linux KubeVirt cluster with CDI, Cilium policy enforcement and Longhorn storage.

It’s for development only: one control-plane node, one database instance and one bootstrap operator, and its readiness receipt always reports productionReady: false. Live VM creation, retry, restart, isolation, complete deletion and recreation haven’t passed this release’s acceptance yet, and roadmap goal G01, a disposable public development installation, hasn’t started.

The recorded state of each part

Source: CURRENT_STATE.md, last reviewed in the repository on 28 July 2026, before both prereleases. roadmap.yaml is the newer status record.

The states come from the repository. Implemented means source and tests exist for the stated use. Reference means a runnable or testable example shows a contract. Experimental is early code that may change. Planned has a roadmap goal but no implementation, and blocked means a known gap stops the stated use.

Capability State What that means
Build, tests, source-safety and supply-chain checks implemented They validate each accepted source revision. They don’t prove a deployed cloud.
OCSv3 package types, validators, Go SDK and conformance tooling reference experimental Testable with synthetic modules. A complete product runtime is planned.
Identity, OIDC and JWT, IAM policy, sessions and audit reference Reusable building blocks. There’s no complete, running identity platform yet.
Transactional PostgreSQL state and migrations reference Implemented and tested, but it doesn’t cover the full control-plane state model yet.
Provider adapters and site profiles experimental Public schemas and validation with synthetic inputs.
kubeadm rendering and Kubernetes deployment profiles blocked Open issues stop a supported independent installation.
Backup, proof signing, restore and resilience observers reference experimental Collectors and protocols exist. There’s no public proof yet of integrated off-site recovery.
Provider control plane, organisations, durable operations and portal planned Roadmap goals G03 to G11.
Network, volume, image, compute, Kubernetes, storage, backup and support products planned Goal contracts exist; the products aren’t built.
Multiple cells and regions, marketplace and federation planned Later roadmap work. Multiple regions and federation come after 1.0.

Design principles

Source: VISION.md. The names are the project’s own.

The project holds its design to ten principles:

  1. No global central dependency. Federation has to fail safely when another provider or a coordinator is unavailable.
  2. Open core, replaceable edges. Reusable capabilities go upstream; deployment values and independently owned modules stay with their owners.
  3. First-class by contract. Every service uses the same documented security, lifecycle, billing, support and evidence interfaces.
  4. Provider and technology neutrality. Core APIs describe capabilities, not one vendor’s products or one deployment topology.
  5. Exit is a product feature. Export, deletion, compatibility and recovery get designed and tested as part of the product, not left to documentation.
  6. Evidence before claims. Static configuration and green unit tests don’t prove a live installation, upgrade, recovery or failure boundary.
  7. Local autonomy and lawful operation. Providers keep admission, commercial, security and jurisdictional control.
  8. One control surface. People, CLIs, APIs, automation and AI agents go through the same policy-controlled operations and audit trail.
  9. Evolution without ecosystem rewrites. Implementations can change behind stable, versioned contracts.
  10. Solve user problems. The platform is infrastructure. The value comes from reliable services that help people get real work done.