A shared request format
Clients describe a resource and its inputs in one shape instead of branching for every provider.
Open infrastructure provisioning / pre-release
Provision infrastructure through one open contract.
OpenProvision is an open protocol for requesting, authorizing and managing cloud resources across providers. The first provider integrations are underway. The draft specification is shared with evaluators and providers who ask for it.
The specification is not on this site yet. If you are evaluating the protocol or considering an adapter, ask for a preview and we will send the current draft.
Current status
OpenProvision is still in development.
The project is independent and pre-release. There is no hosted service, public API, production SLA, certification or price list today. We are working on the protocol, a reference gateway, provider adapters and a conformance suite. The first adapters are in progress.
- Stage
- Protocol and reference implementation
- Specification
- Preview on request
- Hosted service
- None announced
- Provider talks
- Active
01 / The integration problem
Every provider API is a separate integration.
Provisioning infrastructure across providers means learning a different API, authentication model, billing unit, error taxonomy and lifecycle each time. Most teams repeat that work in every client or build a private abstraction that is hard to test.
OpenProvision is exploring one contract for the common path. A client sends a typed request. The gateway handles identity and payment context, and an adapter translates the request to the provider's API. The provider keeps control of its platform.
The scope is small on purpose. This is a resource lifecycle contract, not a universal cloud or a replacement for provider consoles. Not every provider or resource type is supported.
Adapters stay close to providers
An adapter translates the contract to the provider's API. The provider keeps its own semantics and control.
The lifecycle is visible
Create, observe, update and destroy are tracked as one lifecycle, including async work and credential delivery.
02 / For infrastructure providers
Built with providers, not around them.
OpenProvision is being built alongside providers. The first integrations are underway, and we are opening conversations with platform teams who want native support. We care about the technical fit more than a logo, and we are always glad to start another conversation.
What we map together
- The resource types and operations your public API exposes.
- How billing works, including units, rounding, minimums and licence charges.
- Authentication, sandbox access and rate or quota limits.
- Async provisioning, power operations, deletion and failure handling.
- Which parts of the contract map cleanly and which need work.
How we start
- A short technical call with the people who will build the adapter.
- Public documentation first. We sign an NDA if your team needs one.
- A logo or announcement can come later.
- Platform changes can wait until an adapter is mapped and tested.
- Commercial terms can wait until the fit is clear.
Map the fit
We read the docs and have a short call. We list resource types, lifecycle gaps and the billing facts an adapter needs.
Build it together
We implement a narrow adapter, run it through the conformance work and note what your API cannot express.
Grow the relationship
If the mapping is useful, we can discuss official support, resale or a design partnership. We keep the conversation open either way.
03 / Specification preview
The draft is shared, not published.
The specification is not on this site yet. We send it to teams evaluating OpenProvision and to providers who need the contract before a technical call. Tell us what you want to review and we will reply with the current draft and relevant notes.
No newsletter or automated sequence. This is a direct conversation with the people building the protocol and the first integrations.
Request a preview
This form opens your email app. Nothing is sent to or stored on this site.