XE NETS

XE Nets

Install an app. Now you have a cloud.

Turn servers you already own into your own private cloud, with scheduling, storage and billing built in. Only your key runs work on it, until you decide to open the doors.

Talk to us Read the docs

YOUR OWN CLOUD

XE Nets turns servers you already own into your own private cloud, with scheduling, storage, identity and billing built in, and only your key able to run work on it.

Install the node app on each machine, whether it sits in your building, in a colocation rack or with a hosting company, and it joins your net. Your teams deploy services as XE Contracts, and the net decides where they run. It stays closed until you open it, service by service.

SchedulingServices go to the machines that fit them, and move when one fails.

StorageSpace across your own machines, served to your own services.

IdentityEvery machine, team and service has its own account, under your key.

BillingEvery team is billed for exactly the seconds its work ran.

THE PROBLEM

A private cloud, without the platform team.

Most organisations choose between running everything themselves and renting everything from a cloud. A net is the third way.

Run it yourselfYour hardware, and a platform team to run it.

Hardware: Yours
Getting set up: A platform team and months of work
Who decides what runs: You
Billing between teams: Spreadsheets
When you need more: Buy more servers
Idle machines: Sit idle

A public cloudTheir hardware, on their terms.

Hardware: The provider’s
Getting set up: Minutes, then a migration
Who decides what runs: The provider’s rules
Billing between teams: Tags on a monthly bill
When you need more: Pay on-demand prices
Idle machines: Not yours to sell

XE NetsYour hardware, run as a cloud, with the network one setting away.

Hardware: Yours, rented, or both
Getting set up: Install an app on each machine
Who decides what runs: Your key, and only your key
Billing between teams: Per second, per team, built in
When you need more: Pull public capacity in, per second
Idle machines: Publish work to the network and earn

THE BOUNDARY

Closed by default.
Open when you choose.

A net starts private. Publishing a service and pulling capacity in are separate switches, and you can set them one service at a time.

Built on

IdentityDiscoveryPaymentCompute Messaging

Every machine enrolled with your key, and only that key can schedule work on it. Nothing leaves, nothing comes in.

st-marys.policyYour policy

1policy st_marys {
2  schedule    = key("st-marys")      // only this key runs work
3  publish     = []                   // nothing open to outside
4  burst       = none                 // no public machines
5}

In this mode	Publishing	Pulling in
Only your key schedules work on your machines
Your teams are billed per second
People outside can reach it	The services you publish
Your machines earn from the network
Public machines run your work		Only the jobs you send out

HOW IT WORKS

From a rack of servers to a cloud, in three steps.

01Enrol your machinesInstall the app on each server, yours or rented. Each one enrols with your key. No special chips, no migration project.
02Run your servicesDefine them as XE Contracts and they run only on your machines, under your key, with storage, scheduling and billing built in.
03Open up, when you choosePublish services to the public network and earn from them, or pull public capacity in for a busy week. You decide what crosses the wall.

HOW IT WORKS

From a rack of servers to a cloud, in three steps.

01Enrol your machinesInstall the app on each server, yours or rented. Each one enrols with your key. No special chips, no migration project.

02Run your servicesDefine them as XE Contracts and they run only on your machines, under your key, with storage, scheduling and billing built in.

03Open up, when you choosePublish services to the public network and earn from them, or pull public capacity in for a busy week. You decide what crosses the wall.

BILLING BY TEAM

Every team pays for what it ran.

One shared cluster, fairly split. Each team, lab or department has its own account on the net, and every second of work is metered to it.

Metered this monthMachine-seconds

Radiology0
Running on 5 machines · 0% of its budget
Genomics0
Running on 4 machines · 0% of its budget
Research0
Running on 3 machines · 0% of its budget

Per secondUsage is recorded as the work happens, not reconciled at the end of the month.

BudgetsGive a team a budget and it can’t spend past it. The limit is enforced, not reported.

ChargebackThe finance question has a real answer: who ran what, on which machines, for how long.

PROOF · EDGE NETWORK

Edge Network is an XE Net that opened its doors.

Edge has run as a net on XE from day one, and opened it to the world. Every one of its machines is an account on XE, paid for the work it does, and its customers are served by hardware Edge doesn’t have to own.

5K+MachinesEach one enrolled with a key, each one paid per job.

988LocationsSpread across the countries its customers need.

3K+Paying customersServed by machines Edge doesn’t have to own.

100%UptimeWork moves when a machine drops off.

FOR BUILDERS

The same tools,
on your own machines.

A net speaks the same contract language as the public network. Write a service once, then run it inside, publish it, or burst it out by changing one line.

EnrolOne command per server, under your key

DeployXE Contracts, pointed at your net

PolicyWhat runs, what’s published, how far you burst

imaging.xe

1contract imaging_api {
2  image    = "st-marys/imaging:3.2"
3  gpu      = any
4  memory   = "32 GB"
5  replicas = 4
6
7  where    = net("st-marys")  // your machines only
8  network  = none             // nothing leaves the building
9  team     = "radiology"      // billed to the team that runs it
10}
11
12

FOR AGENTS

Agents that work inside your walls.

Give an agent a key to your net and it can schedule, scale and pay for work there, and nowhere else. The boundary holds for agents exactly as it does for people.