Sovereign Cloud Platform

It is software for running AI workloads on infrastructure you control. Your teams get the things they need day to day: endpoints to call models, clusters to train them, and GPUs that are kept in working order. Your organisation keeps the data, the encryption keys and the record of who did what. It can run in your own data centre, in a cloud region you pick, or on machines with no internet connection at all.

Most systems encrypt data while it sits on disk and while it travels across the network, but have to decrypt it in memory to actually work on it. That moment is the gap. Here your data and your model weights stay encrypted in memory too, so someone with access to the physical server still cannot read them while a job is running.

Before a workload starts, the machine produces a signed report of exactly what software it is running. If that report does not match what is expected, the workload does not start, and the checking carries on while the system runs. Separately, each customer gets their own compute, storage and network paths, so one customer's traffic and data never cross into another's.

Yes, and it works the same way either way. Whether the site is connected or completely cut off, it is the same software and the same day-to-day routine. There is no reduced offline edition to learn separately.

Three options. In your own building on your own hardware, with us supplying the software and the operating practices. In a cloud region you choose, so the data physically stays in that region. Or on a site with no outside connection at all. Which one fits usually comes down to the rules you have to answer to.

The GPU servers and the network joining them together. It can hand your teams whatever shape of cluster they work in, whether that is bare machines, virtual machines, containers, Kubernetes or Slurm, and manages all of them the same way so your operators learn one set of tools instead of five. It also configures the network switches for you, keeps each customer's traffic on its own paths, and collects the readings from the GPUs, the servers and both kinds of cluster networking (Ethernet and InfiniBand) into one view rather than half a dozen dashboards.

That is what the automation is for. Bringing nodes into service, watching their health, configuring the network, applying patches and dealing with failed hardware are all handled by the platform rather than by someone working through a runbook. Your team decides the policy and reviews what happened; the repetitive work is not theirs to do.

The platform deals with it instead of waking somebody up. It notices the warning signs a failing GPU gives off, such as driver errors, overheating or faulty memory. It then stops new work being sent to that machine, moves the jobs already running on it somewhere safe, collects the logs needed to establish what went wrong, and attempts the fix: a reset, a reboot, or a ticket if the hardware has to be replaced. The machine stays out of rotation until it is healthy again.

A written record of what the platform did and when. Each update or change is logged against the machine it touched, along with the check that confirmed it worked. Alongside that you get a current list of the hardware you have, the health of each machine, and anything whose settings have drifted away from what they are supposed to be. When someone asks what happened to a particular server on a particular day, the answer already exists instead of being pieced together afterwards.

There is no standard price list, because no two deployments are the same size or shape. The cost depends on where it runs, how many GPUs you have and how much of the running you want us to do. The quickest way to get a number is to tell us what you are working with, and we will size it with you.