Oasis Stack Oasis Stack A CloudHost Initiative
EN
Talk to us
Three independent cloud module stacks on their own plinths, joined only by glowing conduits through a glass federation hub
Services cross.
Customer data stays home.
Architecture · Federation

Independent by design.
Connected by choice.

Each cloud keeps its own infrastructure, customers, pricing and operations. The federation layer carries services, discovery and opportunity between them — customer data never moves automatically.

Talk to us Oasis Federated Cloud
ConnectPublishSell & consumeSettle
Ownership stays homeCustomers, pricing, margins
Sharing is explicitYou list what you share
Data does not travelNever moves automatically
Ownership stays home
Your customers, your pricing and your margins remain yours.
Sharing is explicit
Each cloud lists only what it chooses to share, and with whom.
Data does not travel
Customer data never moves automatically.
Flat participation fee
Participation is a flat fee, not a consumption bill on your own growth.
How federation is structured

One core at the centre. Every cloud in control of its own.

The Oasis Federation Core sits at the centre of the Oasis Stack admin centre, hosted by CloudHost across multiple locations in redundancy. Financial and contractual transactions between locations and between clouds go through it; workloads and data do not. Each cloud keeps control of its own resources, tenants and customers.

The Oasis Federation Core
Controls federation transactions and the publishing of services: what is published, to whom, under which agreement, and how it is settled. It also provides platform licences, keeps the federation healthy and provides central service management.
Each cloud
Runs its own management plane through Oasis Core, which holds the local federation connection and sits in the deployment by design. Its workloads, tenants and customers stay its own.
Customer data
Never moves automatically. Services cross by agreement; data crosses only where you deliberately place it.
Two scopes

Connected to the core, or federated privately.

Connected to the core
Your cloud joins the Oasis federation: it publishes services to other Oasis clouds, consumes theirs and settles through the platform.
A private federation, in-country
A federation for one country, with its own in-country Federation Core as one of the local federation deployments. Clouds inside it connect to each other, and the federation as a whole stays isolated from other regions.
Federated or isolated
Oasis Enterprise Cloud and Oasis Edge Cloud deployments can federate to the core, or stay isolated, as the regulator or the business requires. Air-gapped deployments have no federation and no connection to the admin centre.
The four moves

Connect. Publish. Sell. Settle.

Federation is a business process, not a network diagram. Four moves take two clouds from a signed agreement to settled revenue. Each cloud’s Oasis Core connects to the Oasis Federation Core, which carries the exchange.

1
Connect
A service is published to the federation, and the Oasis Federation Core brokers it between the clouds that carry it.
2
Publish
Each cloud lists the catalogue items it is willing to share, and to whom.
3
Sell & consume
Customers order a federated service on their home account, from their own portal.
4
Settle
Usage is metered; the delivering partner invoices CloudHost, and CloudHost invoices the requesting partner. Customer data never moves automatically.
A federated purchase

Sold under your brand. Delivered by another partner.

A customer can order a service that runs in a region owned by another federated partner. The purchase is white-labelled and brokered through the Oasis Federation Core, and support cases are routed between the two partners through the helpdesk.

  1. The customer ordersFrom the requesting partner’s catalogue, in that partner’s brand.
  2. The service runsIn the region or location the customer chose, run and owned by the delivering partner.
  3. The delivering partner invoices CloudHostFor what it delivered, through the Oasis Federation Core.
  4. CloudHost invoices the requesting partnerWho bills its own customer, as for any other service.
What stays, what travels

The boundary, stated plainly.

Federation is often sold as a network of clouds. In practice the only question that matters is what crosses the boundary — and what never does.

Security & sovereignty
Stays in your cloud
Customer accounts and contracts
Customer data and workloads, unless you place them in a partner cloud
Your pricing and margins
Your infrastructure and operations
Travels by agreement
Catalogue items you choose to share
Service orders and their fulfilment
Usage records for settlement
Discovery of what other clouds offer
Why it grows the business

Four reasons to federate.

Reach, supply, capacity and economics — without giving up ownership of any of it.

Reach
Sell to the customers of other Oasis clouds through their storefronts, in markets you never built a presence in.
Supply
Offer services you do not run yourself: GPU, DR sites, ISV software and managed services from partner clouds, under your brand.
Capacity
Burst, fail over or place workloads in a trusted federated cloud, by agreement, when your own zones are full.
Economics
A flat participation fee instead of consumption bills, with federated purchases invoiced through CloudHost.
What actually crosses

Seven kinds of data. Seven different answers.

“Data never moves” is easy to say and hard to keep once bursting or disaster recovery is involved. Here is the version that holds.

Identity metadata
A signed assertion only
On a federated order, so the serving cloud can prove who is asking. Your directory stays yours; no credential or user record is copied.
Catalogue entries
Yes — what you publish
Only the services you choose to list, and only to the clouds you list them to. Publication is an explicit act, not a default.
Orders and fulfilment
Yes
A federated order carries what was ordered and the tenancy it belongs to, so the serving cloud can provision it.
Usage records
Yes — as counts
Metered quantities for settlement. Not the contents of the workload that generated them.
Workload data
Only where you place it
This is the honest one. If you burst, fail over or run DR into a partner cloud, the workload and its data run there — because you configured that, deliberately, under an agreement. Nothing places itself.
Backups
Only where you target them
A backup or DR target in a partner cloud moves data there by design. It is a configuration you make, and it can be constrained by policy to classifications you allow.
Customer records
Never
Accounts, contracts, pricing and the commercial relationship stay in the cloud that owns them. There is no path that moves them.

The rule underneath all seven: nothing crosses a boundary that you have not published, ordered or placed there. Federation moves commerce by default and workloads only by configuration — which is why a sovereign programme can participate in it without the boundary becoming theoretical.

Trust and failure

What happens when a federated cloud goes away.

A federation is only as credible as its worst day. These are the failure modes that matter and how the model handles each.

A partner cloud is unreachable
Degraded, not broken
Your own services are unaffected — they never depended on it. Federated services you were reselling become unavailable to order, and existing ones behave as that cloud behaves.
A partner leaves the federation
Withdrawal, then unwind
Published catalogue items stop being orderable. Running services are wound down under the terms of the federation, not switched off unilaterally.
A dispute over usage
Both sides hold records
Metering is recorded by the serving cloud and the ordering cloud. Settlement reconciles two independent records rather than trusting one.
The admin centre is unavailable
Transactions wait
Financial and contractual transactions and new publishing wait for the link to return. Workloads are not affected, and the admin centre itself runs across multiple locations, in redundancy.
A partner is compromised
Blast radius is the agreement
There is no shared control plane or identity store: each cloud keeps its own, and exchanges between clouds go through the Oasis Federation Core. What is exposed is what that cloud was published to — nothing behind your own boundary.
You want to leave
Publication stops
Federation is participation, not dependency. Withdrawing stops publication and consumption; your cloud, customers and catalogue continue unchanged.
The partner kind
This page is the mechanism. Federated Partners in the ecosystem covers what an operator brings, what they take away, and the two programme levels.
Federated Partners
Who builds what

Built in-house. Extended with alliances.

The federation mechanism is ours. What travels across it can come from anyone in the ecosystem.

Built in-house
  • Publishing a service to another cloud, and consuming one back
  • The agreement between clouds, and what it allows
  • Settlement between clouds through the commercial engine
  • The rule that customer data never moves automatically
Built with alliances
  • Marketplace alliance applications, published once and offered by every federated cloud that chooses them
  • Technology alliance services, integrated once and available across the federation
How alliances join
Local strength. Global opportunity.

Grow beyond your own market.

A conversation about what you would publish, what you would consume, and the agreement between them.

Talk to us Oasis Federated Cloud