The whole cloud business, in one architecture.
Most cloud platforms stop at the infrastructure console. Billing, contracts, partners, the marketplace, identity, compliance and continuity are left to other systems, bought and stitched together by the operator. Oasis Stack builds them into the stack, above infrastructure you own, and connects it to other clouds that made the same choice. This page shows where each one lives, and why it was built that way.
An operator built the platform it needed.
The trade the industry settled on: a cloud that works, or a cloud that’s yours.
A real cloud was assumed to take capital only a handful of global companies could raise. Governments were offered a region. Operators were offered a reseller agreement. Enterprises were offered speed in exchange for the estate.
CloudHost did not start as a software company. It started as a cloud operator, and it runs YallaCloud, its own public cloud, on Oasis Stack in production. The architecture came from running a cloud, not from selling one: every layer exists because an operator needed it.
What is usually bolted on is built in.
A cloud management platform provisions and automates. Everything a cloud business needs around it is normally a separate system, integrated and kept in step by the operator. In Oasis Stack, each one is part of a layer, shares one identity, one catalogue and one set of records, and is upgraded with the platform.
- Billing and invoicing
- Quotes and CPQ
- Contracts
- Partner and reseller management
- Marketplace
- Identity and access
- Compliance evidence
- Monitoring
- Backup and DR
- Helpdesk
Each one bought or built separately, integrated by the operator, and kept in step through every upgrade.
Built by Oasis Stack, a CloudHost product, or integrated once and validated, and shared by every module. All seven layers
Comparing by category of platform instead? How Oasis Stack compares
Nine things the architecture adds, and where each one lives.
What an operator, a government or an enterprise gets from the stack, grouped by what it is for. Each links to the page that shows how it is built.
One central core. Independent deployments.
Oasis Stack is a management and orchestration layer. Each deployment is installed above infrastructure that is already running, and connects to the rest of the federation through one central core. Air-gapped deployments are fully local, with no link at all.
The seven layers, and what runs in each.
A reference view of the platform: what each layer is for, the components in it, who builds them, and what the platform itself is built with. Each layer links to its page.
The commercial and control steps sit in the path.
Most platforms provision first and reconcile the business and the audit afterwards. In Oasis Stack, every order placed through the platform passes through all seven steps, whoever places it and whatever it provisions.
- 1OrderedFrom the customer portal or an API.
- 2PricedAgainst the catalogue and the commercial engine.
- 3CheckedIdentity and approvals, and policy with the Governance module, before anything exists.
- 4ProvisionedOn the underlying infrastructure, through its integration.
- 5MeteredUsage recorded as it is consumed.
- 6InvoicedBilled, collected and partner margins settled.
- 7RecordedEvery step written to the audit trail.
Different readers. One architecture.
What each person around the table gets from the same stack, and the pages worth reading first.
Eight decisions shaped the architecture.
Read from the infrastructure up. Each one departs from how cloud platforms are usually built, and each has its own page with the detail.
- 01 A layer above, not a replacement Most platforms ask you to migrate onto their stack. Oasis Stack sits above the infrastructure you already run, so the estate stays and the cloud arrives. HowYour infrastructure is deployed first. Each technology is connected once and published as catalogue items carrying price, quota and policy. Technology
- 02 Shared foundations, independent modules Seven modules share one identity, one catalogue, one billing engine and one governance model, so each can be adopted when it is needed. HowModules are installed as separate deployments on the shared services, not as separate products to integrate. The seven modules
- 03 The business is part of the stack Most architectures stop at the infrastructure console. The layers that turn infrastructure into a cloud business are designed in, not bolted on. HowEvery order passes through the commercial engine: quoted, contracted, metered and invoiced by the platform that provisions it. Commercial
- 04 Operated by design Continuity is a property of the platform, not a second project run on a bad day. HowWorkloads run on the infrastructure, not inside the management layer, and Amin watches health, capacity and cost continuously. Reliability & Operations
- 05 Control before creation Policy is evaluated when something is ordered, not discovered in an audit months later. The certificate stays with the operator. HowIdentity, approvals and policy are applied before provisioning, and every action is written to the audit trail as it happens. Compliance & Evidence
- 06 Every boundary is a decision Where data lives, who holds the keys and who operates the platform are decided, not inherited from a provider. HowLocation, key custody and operator are set per deployment in platform policy. Customer data never moves automatically. Security & Sovereignty
- 07 Connected, never merged Independent clouds trade services by agreement without handing over control of their own cloud. HowFinancial and contractual transactions between locations and clouds go through the Oasis Federation Core. Workloads and data do not. Federation
- 08 One platform at every size A mini edge deployment, an enterprise cloud, an operator cloud and a national cloud run the same software. HowModules are installed per deployment and upgraded centrally, or on site for an air-gapped deployment, so every size stays on the same platform. Deployment Architectures
One platform, placed four ways.
Where the management plane and the workloads run, what each deployment connects to and who operates it, set out offering by offering.
Leaving is part of the design.
Your infrastructure is deployed first, and Oasis Stack orchestrates above it. The platform’s own records — customers, contracts, usage and invoices — are held in PostgreSQL inside your deployment. Leaving removes the management and orchestration layer. The virtualisation and the infrastructure underneath stay with you, as long as they are not CloudHost products.
Where a module or product was built end to end by CloudHost — including VirtueSuite for identity and access management, Observa for observability and Oditr for compliance as a service — the exit is planned and built with you, so the dependency is known before you depend on it.
Read it with your team. Then walk it with ours.
Start with the technical resources. When you want an architect in the room, we will walk the design against the estate you run and the cloud you intend to build.