Inside CEP: the three-tier architecture behind a white-label cloud

The Cloud Enabler Platform lets a hosting provider or telco sell cloud under its own brand. Under the hood it's three tiers, each with a single responsibility.

Tier 1: the frontend

A Next.js/React Progressive Web Application — the branded console tenants actually see. It's white-label by design: the operator's logo, domain, and color scheme, not ours. Everything a tenant does here (create a VM, attach a disk, invite a teammate) is an API call to the tier below.

Tier 2: the backend

A Go REST API server that owns the two hardest problems in multi-tenancy:

• Authentication and authorization — who you are, and which organization and project you belong to.
• Tenant isolation — every request is scoped to its tenant before it touches the cluster plane. A tenant's UUID is not a suggestion; it's the boundary the entire API enforces.

Keeping this tier stateless makes it horizontally scalable and — just as important for our customers — auditable.

Tier 3: the cluster plane

Plain Kubernetes, extended with the virtualization stack:

• KubeVirt CRDs to run full virtual machines as first-class Kubernetes workloads
• CDI DataVolumes for importing and cloning disk images
• Calico for network policy between tenant workloads

This is the tier that makes CEP portable. Any conformant Kubernetes cluster — on AwaniOS, on existing hardware, in a colocation cage — can become cloud capacity.

Why three tiers and not two

The tempting shortcut is letting the frontend talk to Kubernetes directly. We didn't, because the API tier is where sovereignty guarantees live: tenancy scoping, quota enforcement, audit trails. Concentrating that logic in one Go service means the security-critical code has one home, one test suite, and one deployment unit.

More in the CEP documentation — including the FAQ on how tenancy maps to Kubernetes namespaces.