Webinar: The whitesky.cloud Federation

In the whitesky Federation, independent cloud enablers offer their cloud locations to each other. Their virtual cloud operators (VCOs) and customers can then deploy wherever a federated location exists, under their own brand, through one portal, on one invoice.

This page is the complete webinar to read at your own pace. It covers why whitesky exists, how the model works, how billing flows through the chain, and two screencasts recorded live on production whitesky.cloud locations in Kampala (Uganda) and Brussels (Belgium).

Why whitesky

Sovereign cloud. Locally owned, globally connected.

Today, sovereign cloud capacity sits in isolated islands. Organisations face:

• vendor lock-in with hyperscalers,
• licence shock, especially VMware customers,
• data under a foreign jurisdiction,
• and local operators who cannot reach scale on their own.

whitesky connects those islands into one sovereign, federated grid. Every location stays locally owned and under local jurisdiction, and every location added makes the grid more valuable to every other participant.

How it works: three roles, one federated grid

The model has three roles, each owning what it does best:

• Virtual Cloud Operators (VCOs): MSPs, integrators and resellers. They own the brand, the customer relationship and the pricing, on white-label portals.
• Cloud Enablers: telcos, data centres and hosters. They own the hardware and the physical location, so the capex sits with them.
• whitesky.cloud: owns the software (the cloud stack, the operator control plane and federated billing) and manages the grid. The locations themselves stay owned by the Cloud Enablers.

The Federation ties every location together: one identity, one bill across operators, and capacity shared across the grid. Many locations, one cloud.

What you get: one stack, fully owned, AI-ready

A single, fully owned stack, from bare metal to AI:

• Foundation, built in-house end to end: KVM, storage and billing. No third-party licences, ISO 27001 certified.
• Operator control plane: what makes the Cloud Enabler / VCO model work, with white-label portals, metering and billing, and reseller separation.
• Every workload: virtual machines, managed Kubernetes, S3-compatible object storage and virtual desktops.
• Sovereign AI: pooled GPUs and private AI with fixed, predictable pricing instead of per-token billing.

Proven, and ready to scale:

• TRL 9: Technology Readiness Level 9, six years in production
• ~50 launching partners and paying customers
• 18 locations in 8 countries
• 0 licence dependencies

Scenario 1: one VCO, two continents

Meet the cast:

• Roberto Carlos, Gigify Uganda, a cloud enabler in Kampala
• John Smith, GIG.Tech NV, a cloud enabler in Belgium
• Dynagrid, a VCO of Gigify, selling cloud under its own brand on portal.dynagrid.tech

Dynagrid needs compute capacity in Belgium. Gigify has no location there, so Roberto calls John, a fellow cloud enabler in the whitesky Federation. John grants Dynagrid access to the Brussels location, both cloud enablers check the prices they charge each other, and minutes later Dynagrid sells Brussels under its own brand.

Note what is not needed: a contract between Dynagrid and GIG.Tech. The whitesky Federation handles it.

Scenario 2: how billing works

One unit system

The whole Federation uses one unit system as its common billing denominator. Allocation units are paid for what you reserve; consumption units for what you use.

From usage to invoice

Usage is metered every 15 minutes and rolled up into monthly invoices. Every level invoices the next, with its own prices and its own currency:

1. whitesky.cloud invoices the cloud enablers for platform consumption.
2. A cloud enabler invoices its VCOs, and other cloud enablers for roaming capacity. Cloud enablers settle roaming capacity among themselves.
3. A VCO invoices its customers, at its own prices.
4. The customer gets one detailed invoice.

Every level sets its own price

The real prices from scenario 1, for one storage unit (SU = 1 TB of disk for a month) in Brussels:

Each party adds its own margin and can use its own currency; the Federation settles each step. Two cloud enablers and one VCO each decide their own price, and the customer still gets one invoice.

Scenario 3: one network, two continents

Dynagrid’s customer Kampala Craft Brewers runs its workloads in Kampala, on Gigify Uganda’s location, and wants a second site in Europe.

1. Dynagrid enables Brussels (GIG.Tech NV’s location) for them.
2. The customer builds a cloudspace and a virtual machine in Brussels, and pings it from Kampala: no reply. Two separate networks.
3. The customer connects the two cloudspaces over a VPN between their virtual firewalls, all self-service. The replies from Brussels arrive.

One private network across the whitesky Federation, on two continents.

The whitesky Federation in short

• Cloud enablers trading compute among themselves inside the Federation
• Two continents
• Two cloud enablers: a Ugandan and a Belgian one
• One VCO, with a billable client that needs sovereign compute on two continents, under two different jurisdictions
• Set up in minutes

  Download the slides (PDF, 2.5 MB)

Join the Federation

Want to offer your cloud locations to the Federation, or deploy on federated locations for your customers? Read more about the whitesky Federation or request a demo.