Cloud infrastructure for a world with many providers
CloudRING is an open-source platform being built for running a cloud on your own hardware. At its centre is OCSv3, an open contract between a provider's platform and the services it offers. It's meant to let a service be built once and run by any provider that adopts the contract.
Early development CloudRING isn't ready for production or pilot use. The latest release is v0.1.0-c02.1, a development prerelease from 7 September 2026.
What exists today
Source: the README and the public current state in the repository.
The repository already holds early pieces of the platform, with tests you can run from a fresh clone:
- OCSv3 package types, validators, a Go SDK, conformance fixtures and a module registry contract, with a synthetic reference service to try them on.
- Identity and access building blocks: OIDC and JWT handling, IAM policy evaluation, secure sessions and audit records.
- Transactional PostgreSQL state and migrations, a first piece of the control plane's state model.
- Provider-neutral site inventory, kubeadm rendering and HA verification contracts.
- Backup proof collection, proof signing, one-server-loss observation, an HTTP security probe and source-safety tooling.
What isn’t there yet: a complete installer, the provider control plane, a production portal, billing, a reference cloud product from end to end, a provider pilot and federation between providers. The roadmap puts them in delivery order.
Why CloudRING exists
Source: VISION.md, “The problem” and “Design principles”.
A public cloud usually bundles four choices into one package: who runs the hardware, which control plane manages it, which services you can use and which jurisdiction governs all of it. That’s convenient until you want to change one of them. Smaller providers and in-house infrastructure teams keep rebuilding similar control planes. And every team that builds a cloud service has to integrate with each cloud separately.
CloudRING pulls those choices apart. A provider runs the open platform on its own infrastructure, services plug in through the same contract wherever they run, and leaving is treated as a product feature: export, deletion and recovery are part of the design from the start.
Where to start
- For providersFor cloud providers and infrastructure teams: what CloudRING is meant to give you, and how far along it is.
- Build a serviceFor service developers: the OCSv3 contract, the SDK and the conformance checks.
- ContributeCode, tests, adapters and documentation, all through pull requests.
- Review the securityHow CloudRING is built and released, and how to report a vulnerability.
- Follow releasesWatch the repository's releases on GitHub. The roadmap calls for a signed prerelease at the end of each goal.
- Get in touchQuestions about the project.
How the project works
Sources: GOVERNANCE.md, the security workflow and the release guide.
CloudRING has one lead maintainer, Yuri Trukhin, who decides what gets merged and is accountable for it. AI agents help write and review code, but they don’t have the final say. Every pull request runs CodeQL, gosec, govulncheck and a secret scan of the whole tree and every new commit. Before a release is attested, the Linux release bundle is built twice with separate caches, and the two builds have to match byte for byte.