Uptime: A Cloud Provider Sim

Uptime: A Cloud Provider Sim is a first-person management simulation about building and operating a cloud provider. You walk the data center floor, buy and carry servers, install them in racks, run cables between ports and power on the equipment. Then you sign customers and keep their services running as traffic puts your setup under pressure.

Build and operate your provider

You manage the full stack: physical hardware and networking, the services you sell, and the customers whose products depend on your equipment. Servers, switches, cables and ports are live entities in a deterministic simulation. Power and cooling are limited budgets, hardware capacity fills up, and failures follow the model rather than occurring on random timers. When something goes wrong, you have to diagnose and fix it.

You can sell virtual machines, object storage, managed databases, Kubernetes, load balancers and serverless functions. Each service has a control plane that must stay available and agents on the hosts that do its work. Services compete for the same computing resources as your customers, and network layout affects whether they can reach what they need. A service can fail if it loses contact with its control plane, buckles under too much demand or is partitioned by the network.

Customers and reputation

Customers have names and products that rely on your infrastructure. You earn their trust gradually but can lose it in a single bad night. Taking on a deal you cannot support, overfilling a host or missing an SLA breach can cost you the reputation that would have brought in further customers. Before signing, you can check whether your capacity fits the deal, and sometimes turning business away is the right choice.

Customers can surge in demand, haggle and ask for more capacity. Their requests may need more bandwidth, memory or CPU, and keeping them happy can lead them to recommend you to others. Incidents have no preset severity labels: their severity depends on how many customers are affected and how badly. Runbooks and a codex in the console help you respond, while customer messages report requests, complaints and the effects of changes you make.

Network and infrastructure

The simulation models ports, cables, power draw, fault domains, oversubscription, link aggregation, spanning tree, BGP and mean time between failures. Links saturate when their capacity is used, and a poorly planned fault domain can create a single point of failure. Redundant links can be protected by spanning tree when configured correctly; a loop can instead cause a broadcast storm. You can play without engaging deeply with these systems or work through their details.

Network equipment includes managed Layer 2 and Layer 3 switches that form a switching fabric. Typed connectors and media rules govern which cables fit, while link aggregation and breakout cables use the capacity of their member lanes. Patch panels connect front and rear faces, and cable-management routes have finite capacity. Reachability from a host through switches and the demarc to an uplink determines whether resources can be allocated. Capacity also depends on how workload requirements fit a host's hardware, rather than on a single capacity bar.

Machines draw power and wear over time. As a machine ages, its disk speed falls and its power use rises, but its purchased memory and cores do not disappear. The financial model tracks burn rate, runway, costs by customer and upstream transit charges based on the traffic you send. Hardware stops depreciating once it is written off, and reputation reflects both the capacity you can provide and the impact of incidents.

Defend your network

Flood attacks become more frequent as you grow, and their volume depends on your tenant count, how well known you are and the capacity of your line. Attacks cannot arrive faster than the line allows, so consumer fibre and carrier circuits face different attack patterns. Gateway add-ons can scrub some traffic, but even traffic they absorb has already used your incoming capacity. Up to four fifths of a circuit can be taken, squeezing your service without switching it off.

You can buy more inspection capacity or more line capacity. An intrusion feed shows attacks as they happen, and security hardware adds monthly fees and licences to your running costs.

Campaign and scenarios

The Garage to Glory campaign follows your growth from one server in a garage to a data center floor, through a basement build-out and into a room you fill and defend. Garage to Glory: Hard follows the same climb with half the cash and half the leads, steeper targets at every stage and a run about two and a half times as long. Arm Race offers a different start, and an open sandbox lets you build without set constraints.

Scenarios are readable files that the community can use to create starts, disasters and constraints. The data center floor can expand with rows and cages, and you can spread customers across separate zones. The game also includes difficulty settings of Easy, Standard and Hard, which retune the simulation from a neutral baseline and can be changed during a run. Hard scenarios set their own minimum difficulty, so the setting can make them tougher but not easier.

Learn the systems

NPC mentors guide new players through the game. A jargon toggle switches the interface between plain language and technical terminology while keeping the underlying systems the same. The console also includes runbooks and a codex that fills out as hardware arrives.

Monitoring tools

Each running game provides a read-only HTTP API on localhost, with its port shown in the ops console. It returns JSON for collections including hosts, racks, cables, switches, tenants, incidents, work orders and quests. A generated OpenAPI specification and Swagger page are included, and a Prometheus /metrics endpoint can feed monitoring dashboards. The engine supplies the HTTP side with a copy of its state on a fixed cadence without waiting for requests, and each response includes its age.

Multiplayer

Multiplayer is in beta testing. It is planned for several players to share one floor and one set of customers, with players able to divide tasks such as installing hardware, running cables and monitoring graphs.

Technical model

The simulation runs in a deterministic Rust engine, and the renderer displays the state the engine has decided. Runs are replay-stable: the same seed produces the same run. Scenarios and mods use human-readable files, and the engine can be tested without the renderer.