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. It is in active development. 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.
- Stage
- Protocol and reference implementation
- Specification
- Preview on request
- Hosted service
- None announced
- Provider talks
- Open
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
A technical conversation before a commercial one.
We want to understand how a common provisioning contract fits real APIs and real bills. This is pre-release work. We are not asking for an endorsement, an SLA or a commercial commitment. We would rather learn how your platform works than pitch a partnership.
Useful to discuss
- 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 do not.
What we are not asking for
- A production SLA, exclusivity or a public endorsement.
- Customer data, credentials or confidential material over email.
- An NDA before we can read public API documentation.
- A commercial commitment before the technical fit is clear.
- Platform changes before an adapter has been mapped and tested.
Start with the public API
We read the docs and have a short call. We list resource types, lifecycle gaps and the billing facts an adapter needs.
Build a narrow adapter
We implement a small adapter, run it through the conformance work and note what your API cannot express.
Decide what comes next
If the mapping is useful, we can discuss official support, resale or a design partnership. If not, we say so.
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.
Request a preview
This form opens your email app. Nothing is sent to or stored on this site.