Patch notes
Every release, in full.
Release notes and announcements, pulled straight from the game's Steam page. Want the design write-ups behind them? Those live in the Devlog.
- Read on Steam →New
This release is a major expansion of the VXLAN network isolation you already had, and a ground-up reimplementation of the old service pools. The private networks you could hand out per customer now reach all the way down to the individual service, machines can be organised by the job they do, and the whole thing is finally visible across the datacenter instead of being an invisible setting.Network isolation & placement- VXLAN isolation, now down to the individual service. You could already put a customer on their own private network so no other tenant could reach them. That now goes a level deeper: inside a customer, each service sits in its own zone, so their database is walled off from their website and a break-in on one can't wander into the other. By default every customer still shares one open network and it all just works; isolation is something you add when a customer asks for it, not setup you have to do first. The isolation view in the ops console is rebuilt to match: it reads as your networks, with the service zones inside each one, and shows which machines are serving what.
- Service pools are back, reimplemented and far more flexible. Reserving machines for a job returns, rebuilt from scratch. Point a group of machines, or a whole rack, at a specific service ("these run databases"), at a specific customer, or at a whole SLA tier ("Bronze object storage lives here"). It's one gesture with two dials: what runs here, and, optionally, who for. Any customer's databases can share a database pool while staying network-isolated from each other, or a single tenant can be handed the pool to themselves. A new Machines list in the isolation view shows every reservation and who it serves, and if a reservation can't be met the game says so out loud instead of quietly stranding the workload.
- Private network and private hardware are now separate choices. Giving a customer a private network no longer drags their workloads onto special machines. Keeping a customer's traffic to themselves (the network) and keeping their data on hardware nobody else touches (the machines) are two independent decisions. A compliance customer can have just their database on dedicated iron while the rest of their services stay on the shared floor, network-isolated but sharing hardware.
- Shape a machine group one machine at a time. Reserving machines is now a two-panel editor in the isolation view: your groups run down the left, and the selected group opens on the right with the machines already in it, a button to drop any one of them, and a picker to add more. You can build a group from the other end too: walk up to a machine, open its console, and home it to a customer's network or a single service on the spot. Growing a group leaves the machines already in it exactly where they are, so you can keep adding to a pool instead of tearing it down and starting over.
- Some customers now pay for isolation, and pay well. A handful of tenants across the tiers arrive asking to be walled off, and it shows on their decision card. Wanting their own private network bills at twice the normal rate; wanting that network on dedicated, single-tenant machines bills at four times. It is worth real money because it costs you real capacity: a private-network tenant that also needs their workloads spread across separate machines stacks both premiums, since you are handing them several exclusive boxes. So far a backup provider, a high-frequency trading desk, and a bank's core ledger want the dedicated treatment, while a health-tech startup and a fintech want just the private network. You see the ask before you sign, and the bill reflects it from the first tick.
- Data spreads out to survive failures. Databases and object storage keep copies, and you decide how far apart they sit: across racks, rooms, or buildings. Three copies across three racks ride out losing a rack; pack them into one and a single blown fuse takes the customer down. When a customer needs more spread than your hardware can provide, the game tells you plainly rather than quietly under-protecting them.
- See your networks across the whole datacenter. Isolation is now visible everywhere it matters. The network map tints each machine by the customer and service it's carrying and colours the cables to match; focus a customer and their island lights up while the rest dims. Walk up to a host and its console lists the customers and services it's serving; a switch, gateway, or appliance console shows what traffic is passing through it. Prefer the real terminology? Engineer mode (Tab) relabels all of it in proper VXLAN terms, private networks as VRFs and service zones as L2VNI subnets, with nothing dumbed down, just renamed for the people who run this for a living.
Processor architectures- Servers now come in additional processor types, and some customers care which. Most tenants run happily on anything, so cheap, power-sipping ARM machines are always fair game and stay the margin play. A handful of new customers turn up who are particular about it: an enterprise app that only ships for Intel/AMD, a RISC-V research lab and an embedded firmware shop that both need matching open-ISA silicon, and a bank's core ledger and an insurer's overnight actuarial batch that only run on the mainframe. There are new specialist servers to match, RISC-V and mainframe boxes alongside bigger dual-socket ARM, compute, and memory machines. The RISC-V and mainframe boxes are reserved for the customers who actually need them, so everyday workloads never crowd out that scarce, expensive hardware. Sign a customer who needs a processor you don't own and their machines won't place until you rack the matching kind, and the customer screen names the type to buy.
- New scenario: The ARM Race. A twist on the garage-to-glory campaign locked entirely to ARM. Every server you rack is ARM silicon, lower power and more cores per watt, and you only ever meet customers who run on it, so there is no x86, no RISC-V, and no mainframe hardware anywhere in the run. A focused challenge for anyone who wants to build the efficient way, top to bottom.
Workloads & customers- Move any workload by hand, not just VMs. You could always pick a virtual machine off a server and migrate it to another box yourself. Object storage, CDN, managed Kubernetes, and load-balancer workloads couldn't be moved that way; the only option was to drain the whole host. Now every migratable workload on a server's console has its own Migrate button. Choose the piece you want to move, pick a target server, and the game checks it actually fits (capacity, the right availability zone, and keeping a tenant's copies on separate machines) before committing. If the target can't take it, the workload stays exactly where it was and the console tells you why.
- A customer's requirements no longer disappear the moment you sign them. Everything you weigh on the prospect card, compliance, processor type, spread across zones, private networking, air-gap, audit logging, GPU, and how far they can grow, now stays on their page after they join, so you can always see what you committed to. That same page also lists the exact machines running their workloads and a history of any incidents that touched them, so an accepted customer is a full record instead of a name with the details hidden.
FixesNetworking & cabling- GPU customers now show their GPU requirement. A prospect whose workload needs GPU hardware (AI / VFX / genomics tenants) used to read on the decision card exactly like a plain-CPU one, the GPU ask was invisible, and the "can you serve it?" column could say "Comfortable" even when you had no GPU host at all, then every one of their machines would fail to place the moment you signed. The card now spells out the GPU partition each VM wants (slices and video memory) on the demand line, and the serve column reads honestly: with no GPU host it says "Needs GPU hardware, add a GPU host first" and shows how many GPU slices your fleet has free. Rack a GPU host and it clears.
- Security gateways put the WAN side on ports 1 and 2. The inline 2×25G + 2×10G and 2×100G + 2×10G security gateways were wiring their WAN ports to 1 and 3, with LAN on 2 and 4, which made cabling the internet feed a guessing game. WAN is now the leading pair (ports 1 and 2), matching the smaller gateways, and each side still carries one full-speed uplink. Old saves repair themselves on load: any cable you had already plugged follows its port to the corrected number, so a WAN cable stays on WAN and a LAN cable stays on LAN.
- Port LEDs light only the port they belong to. On multi-row faceplates (the gateways, the larger switches, and the security appliances) cabling a single port lit a whole stack of indicators, including the link and activity lights of an adjacent, uncabled port. Every port now drives just its own two lights, so a green link light always means that exact port is connected.
- Device consoles show the traffic actually passing through them. A switch, gateway, or security appliance sitting in the middle of a path used to read as carrying nothing, even while a tenant's traffic ran straight through it, because it only counted the machines cabled directly to it. Each console now traces the real forwarding path, so it lists every network and service whose traffic transits that box, however many hops away the machines running it sit.
World & interaction- You can no longer walk through the uplink rack. The colo uplink cabinet (and the garage wall rack) shipped without solid collision, so you would clip straight through them. Both now stop you like every floor rack.
- Freed rack slots are usable immediately. After un-racking a security appliance from the uplink rack, the U slots it had occupied stayed greyed out and refused a replacement for a tick or two. They now read as free the instant you lift the appliance out.
UI- Menus stay put on ultrawide monitors. On 21:9 (and wider) displays the main menu and co-op lobby used to stretch to the physical edges, the menu pinned to the far left, the credits and footer to the far right. They now sit in a centred 16:9 column while the backdrop still fills the whole screen, so the layout reads the same as it does on a 16:9 display. If you prefer the full spread, there's a new "Constrain menus to 16:9 on ultrawide displays" toggle in Settings → Display (on by default; it does nothing on 16:9 or narrower screens).
- VXLAN isolation, now down to the individual service. You could already put a customer on their own private network so no other tenant could reach them. That now goes a level deeper: inside a customer, each service sits in its own zone, so their database is walled off from their website and a break-in on one can't wander into the other. By default every customer still shares one open network and it all just works; isolation is something you add when a customer asks for it, not setup you have to do first. The isolation view in the ops console is rebuilt to match: it reads as your networks, with the service zones inside each one, and shows which machines are serving what.
- Read on Steam →New: the prospect decision card
Deciding whether to sign a prospect now opens a rebuilt two-column card. Who they are and what they pay sit at the top, what they want is on the left, and whether you can serve it is on the right.- Every service a prospect wants is spelled out. A database, object storage, functions or Kubernetes customer used to show only a bare tag with no numbers. The card now lists every service they need with its real demand, VMs and otherwise, so you know what you are taking on before you sign.
- Hidden requirements are shown up front. Some customers need more than a site certification. They may need a working SIEM for audit logging, an air-gapped facility, more than one availability zone, or an isolated segment for their tier. These used to turn you away at sign-time with no warning. The card now lists them, split into hard requirements you must clear and softer recommendations.
- Isolate a customer as you accept them. The card can place a new customer on a network segment at the moment you sign. Keep the default (the shared network, or a tier rule that already covers them), add them to an existing segment, or create a dedicated one, optionally reserving hardware for it. Choosing an existing segment uses a searchable list, so it stays usable when you have many.
- Capacity reflects where the customer will actually run. When you isolate a customer onto dedicated hardware, the "can you serve it" read measures that segment's reserved hosts instead of the whole fleet, and updates as you change the isolation choice. You can see whether the dedicated hardware has room before you commit.
Network map- The network map reads clearly at any size. The map used to shrink the whole graph to fit the panel, so on a larger network the labels turned to an unreadable blur. It now keeps text at a legible size and spreads the graph out to use the space, grouping your gear by region and availability zone so a multi-zone network fans out top to bottom instead of collapsing into a thin strip. When the map is bigger than the panel you can drag to pan around it.
- One label per link, not a pile. Where several matching cables run between the same two groups of gear (a redundant pair of uplinks, for example), the map used to stamp a full speed label on every one, so they stacked into an unreadable clump. Those now share a single "x N" label that reads their combined traffic, and the live flow still animates along each individual cable.
- New: see the map as your actual racks. Turn on the Racks view and the map redraws by where your equipment physically lives. Each rack becomes a labelled cabinet with its devices stacked in rack order, the carrier feeds sit inside the rack they terminate in, and the cables route between the cabinets, so you can read "what is plugged into what, and where it is" at a glance. Turn it off to return to the network-flow view.
- Racks show the name you gave them. The map now labels each rack with your own name for it instead of a generic "rack 5".
- Speed labels point to their cable. On a busy map it was hard to tell which speed reading belonged to which cable. Each label now draws a short line back to its cable, colour-matched to the link speed, and sits in the open space near the cable instead of crowding the gear.
Fixes- Breakout cables no longer scramble their route. When you ran a QSFP breakout leg (a QSFP port cabled to an SFP port) and threaded it through cable managers, wall hooks or a rack roof anchor, the committed cable could order its waypoints wrong, crossing over itself into an "X" and looking like it skipped an anchor, even though the preview was correct. The route is now stored in a fixed direction, so the finished cable matches the preview no matter which end you started from. Re-lay any breakout cable that already looks crossed to clean it up.
- QSFP DAC cables are slimmer. The direct-attach copper cables that fan out of QSFP ports were drawn far too thick, so bundles splayed wide and sat badly in cable managers. Every QSFP DAC speed now uses one consistent, slimmer jacket that packs neatly into a manager rail.
- QSFP DAC connectors show their boot. On rack-mounted switches the strain-relief boot, where the cable meets the QSFP module, was not drawn, so the cable looked disconnected from the module. The full connector now renders on every rack device, matching what you see when you inspect a rack up close.
- Device front ports can no longer be reached from behind. On switches and other rack devices, standing on the rear power side let you interact with the front-face network ports straight through the chassis. Front ports are now reachable only from the front, and power inlets only from the rear.
- Renaming a rack renames only that rack. Editing a rack's name used to leave every rack showing the last name you typed, and the change never actually saved. Rack names now save correctly, apply only to the rack you edited, and commit when you press Enter as well as when you click Rename.
- Twinax cables stop reporting a rack as full when it isn't. Threading direct-attach copper cables through the same cable-management finger near the top of a rack could hit a false "24 cables, full" wall while the rest of the rack sat empty. Those cables now spill into the rack's full cable run instead of erroring.
- A customer's Functions stay on their dedicated hardware. If you isolated a customer onto dedicated hosts, their Functions were still landing on shared machines. Functions now respect isolation the same way VMs and every other service do, so an isolated customer's Functions run only on the hardware you reserved.
- The shop updates when you relocate. After moving to a new site, the build catalog kept showing the old site's products until you saved and reloaded. It now refreshes as soon as you arrive.
- A firewall's LAN port cannot be cabled to the gateway. The gateway is the internet-facing side, so running a firewall's LAN port into it was never valid, but the game accepted the cable and then would not let you remove it. That link is now rejected when you try to lay it, and every cable-rejection message reads in plain language that tells you what to do instead, rather than internal port names.
- Device panels show CPU that is actually in use. The in-world device panel showed reserved CPU rather than live load, so a lightly loaded host could look busier than it was. It now shows real CPU utilisation. Memory and storage still show what is reserved.
- The Accept button reads correctly. It only says "Accept anyway" when the fit is genuinely oversubscribed or over capacity, and it now follows your isolation choice: route a customer onto a dedicated segment that is too small and it arms the warning against that segment's hardware instead of the whole fleet. A comfortable fit, or a customer with no VM load, reads as a plain "Accept".
- The prospect card closes with the panel. Leaving the ops panel, or switching to another page, with a prospect card open no longer left it stuck open when you returned.
Notes- No save or network protocol version change. Existing saves load normally.
- Every service a prospect wants is spelled out. A database, object storage, functions or Kubernetes customer used to show only a bare tag with no numbers. The card now lists every service they need with its real demand, VMs and otherwise, so you know what you are taking on before you sign.
- Fixes the bugged migration heal causing lag on load of busy savesRead on Steam →
- This patch adds customer network isolation, fixes how contention and placement read, makes saves rebalance when they load, and includes a cable-rendering fix.Read on Steam →New: network isolation (VXLANs)
You can now separate customers onto their own network segments. A segment is a VXLAN: a private network you place customers on, either by picking them one at a time or by tier. Everyone sits on the shared default network until you move them.
It lives in Operations, under Isolation. Your segments are a list on the left, and the selected segment's detail is on the right. Create a segment, add customers to it, and decide how far the isolation goes.
There are two levels, and the difference matters.
Logical (a segment on its own network). The customer's traffic is separated and a breach is contained. If another customer is compromised, the attacker cannot cross into this segment. The catch is that the customer still shares machines with others, so it can still compete for CPU and memory with whoever it sits next to. Use this to wall tenants off from each other on the network without buying them their own hardware.
Dedicated (reserve hardware for the segment). Reserving machines holds whole hosts for the segment. No other customer's workloads land there, so there is no resource contention from neighbours and you control exactly where those customers run. You reserve from the segment's detail pane: tick the machines you want, grouped by rack, and confirm. Every customer in the segment then moves onto that hardware.
The quick way in. Open a customer and choose Isolate to drop them onto their own segment. If you then want them on their own hardware, reserve machines for that segment in the Isolation view.
Why it matters. A breach only spreads between customers that share a segment. Give a customer its own segment, or its own hardware, and a compromise somewhere else stops at the boundary. The network map has a new Isolation view that colours the fleet by segment, so you can see who sits where and which hosts are reserved.
All of the isolation copy follows the plain and engineering language toggle.Fixes- Contention reads honestly now. After the last patch, some hosts still showed as contended when they were fine. Two things were being conflated. An allocation figure was drawn as if it were live load, so an overcommitted but idle host read as full. And hosts running background service coordination were flagged as busy when they had no real work on them. Utilisation now shows live load separately from committed capacity, a host that is only holding a reservation no longer reads as contended, and a contended host shows what is actually using its CPU, split across VMs, functions, and service overhead.
- Loading a save rebalances placement. If an older save had VMs stacked onto one host by a previous version's placement, that stack used to stay put on load. Now the fleet re-spreads those VMs across your idle hosts on the first tick after loading, so a save comes up balanced rather than frozen in its old shape.
- Segment membership repairs itself. A customer that leaves is now cleaned out of any segment it was pinned to, both when it happens and again on load, so an old save cannot carry stale references.
- QSFP cables no longer cross into an "X" through the cable managers. When two thick QSFP runs shared the same manager rail on a rack, they could twist past each other into a bowtie instead of sitting as clean, parallel runs. Cables sharing a manager column are now ordered by their vertical position, so they nest neatly (the "U" you would expect) rather than crossing. Most visible on QSFP because it is the fattest cable, but the fix applies to every cable in a manager column.
Notes- The old host pools placement tool has been retired. Network segments cover placement now.
- No save or network protocol version change. Existing saves load normally.
- Contention reads honestly now. After the last patch, some hosts still showed as contended when they were fine. Two things were being conflated. An allocation figure was drawn as if it were live load, so an overcommitted but idle host read as full. And hosts running background service coordination were flagged as busy when they had no real work on them. Utilisation now shows live load separately from committed capacity, a host that is only holding a reservation no longer reads as contended, and a contended host shows what is actually using its CPU, split across VMs, functions, and service overhead.
- Read on Steam →Stability
- Added safeguards against a GPU hang and driver reset reported on some Linux systems with AMD graphics (Mesa RADV, RDNA3). On affected setups the highest Global Illumination tier ("SDFGI High") now runs at a lighter quality automatically to stay within the driver's limits, and the 3D render resolution is now capped to a safe maximum even when the resolution cap is set to "None". Your saved Graphics settings are not changed. If you still see a GPU reset, set Global Illumination to Off in Settings > Graphics.
Fixes- Tenants no longer abandon your business partway through a funded site move. Previously, if you chose a longer migration window, customers running functions or object storage could give up (and crater your reputation) hours before the window ended, even though you were still inside the time you agreed to. Carried tenants now wait out the full window with no penalty, exactly as intended.
- Host servers no longer show a false "Contended" warning at normal load. The contention warning now appears only when a host's real CPU demand genuinely exceeds its physical capacity (true oversubscription), instead of triggering at light load.
- The host console's Workloads tab now shows each workload's real CPU usage instead of every workload reading 100%. Different customer workloads read differently again, and a workload that is bursting to the top of its allocation is now clearly marked as 100%.
- New virtual machines now spread more evenly across your servers. A host also counts the work of the services it runs (load balancers, databases, Kubernetes, object storage) when deciding where the next workload lands, so a busy host no longer keeps attracting more.
- The victory screen now shows a readable summary of what you accomplished instead of raw internal condition text.
- Fixed the Approve / Pass buttons on customer growth and request cards, which could show no visible text until hovered and flipped colours on hover.
- Long play sessions no longer grow memory use and save-file size without bound. Message threads belonging to customers who have left are now cleaned up (previously every customer's chat history was kept for the entire run), and a global cap keeps total message history bounded. Existing saves are repaired automatically on load.
- Fixed an error when connecting a cable to a port immediately after equipment in that rack changed, which could cause the click to do nothing and spam the log.
- Internal server capacity bookkeeping (reserved CPU, memory, and storage per host) is now rebuilt from your actual workloads when a save loads, so a rare accounting drift can no longer make a host look fuller or emptier than it really is. Existing saves are repaired automatically on load.
Interface & quality of life- Added a Head Bob slider under Settings > Gameplay. Turn it down for a steadier camera, or all the way to zero to switch camera bob off completely.
- Added an Unstuck button to the pause menu that returns you to a safe standing spot if you ever get wedged in the scenery.
- On the switch, gateway, and appliance consoles, clicking a network port on the front panel (or selecting it in the list) now reveals its row even when "Hide down ports" is turned on, so you can always act on the port you picked.
Notes- No save or network protocol version change. Existing saves load normally.
- Thanks for all the reports. This patch is a bug-bash pass driven almost entirely by your feedback.Read on Steam →New
- A getting-started guide for your first ten minutes in the Garage. A step-by-step walkthrough of the opening: buying and racking your first hardware, running power and network cables, getting online, and signing your first tenant. If you're stuck at the start, read it here: https://playuptime.com/guide.
Fixes- "You've outgrown this site" no longer pops the moment you load a fresh Garage game. The prompt now waits until you've actually met the advance requirements (monthly revenue and active customers), not just because you're holding your starting cash.
- Relocating no longer bleeds your tenants dry during the move window. Picking a migration window (for example the 12-hour planned cutover) now genuinely protects the customers who agreed to wait. Previously, if you moved sites and hadn't rebuilt capacity by the time the window closed, every tenant left at once and your reputation cratered to zero. Carried tenants now leave gracefully and penalty-free if the move overruns, instead of taking the full new-signup failure hit.
- The shop now updates immediately when you relocate. New-site hardware shows up in the buy panel the moment you arrive, instead of only after a save and reload.
- CPU-contention alarms stop flapping. A host whose latency was hovering right on the SLA line used to open and clear the same incident every few seconds. Contention incidents now open right away when a tenant is genuinely breaching, but hold steady and only clear once the host has been healthy for a sustained period. No more strobing alerts.
- Fixed a permanent "network loop" alarm on healthy redundant setups. If you wired a redundant path and Spanning Tree correctly parked the standby leg, the game kept a loop alarm lit forever even though the network was working perfectly and passed failover. A cleanly managed redundant loop is now recognised as the healthy design it is. Genuine problems (broadcast storms from unmanaged loops) still alarm as before. Existing saves clear the stale alarm on load.
- Fixed the rack alarm bar ballooning into the room. Unplugging a cable on an occupied rack could make the status light bar at the top of the rack stretch out into the aisle as a big box. It now stays a thin bar across the top of the rack where it belongs.
- The EDD's management/console port no longer shows a link light. The console jack on the carrier handoff device was lighting up like a live network port. It is a management port, so it now stays dark, matching the console ports on switches, gateways, and appliances.
Progression and balance- Moving up to the Colo is now a proper milestone. Advancing from the Basement to the Colocation site asks for more than before: $80,000 a month in revenue, 60 active tenants, and a 0.55 reputation (previously $60,000, 30 tenants, and 0.40). The Basement has far more cooling and rack space than the Garage, so leaving it should mean you have genuinely built it out and kept your customers happy, rather than clearing the same tenant count you already passed on your way out of the Garage.
- The campaign win is a bigger finish, and you can keep going after it. Taking the crown at the Colo now calls for 100 tenants, $250,000 a month in revenue, and a 0.8 reputation (up from 50 tenants). A reputation that high only holds if you run a genuinely reliable shop. As always, choosing "keep playing" after the victory screen carries your save on so you can keep growing.
- Reputation opens the taps more deliberately. New prospects arrive faster the higher your reputation climbs, and the point at which demand reaches its full flood now sits a little further up the reputation scale. Building and protecting a strong reputation is more clearly the thing that fills your customer queue.
- The advance and win goals now show your reputation target. The objective readout lists the reputation you are working toward alongside the revenue and tenant counts, so you can see every requirement at a glance.
- More from your feedback. This one is about getting unstuck: relocation no longer hinges on cash you have already spent, plus a clearer read on what your next site actually needs, and a few basement fixes. Keep it coming on Discord: https://discord.gg/V7YVmA2Fux.Read on Steam →Progression and relocation
- Relocation now unlocks on the size of your business, not the cash in your account. Moving up is a funded relocation that carries your customers and capital forward, so it never costs you liquid cash to make the move. The old cash gates were quietly punishing the players who did the sensible thing and reinvested in hardware, leaving a thriving operation stuck with a full book of customers and an empty wallet. Sites now unlock on monthly revenue instead:
- Garage to Basement: reach $20k/mo revenue with 30 active customers.
- Basement to Small Colo: reach $60k/mo revenue with 30 active customers and 0.40 reputation.
- Garage to Basement: reach $20k/mo revenue with 30 active customers.
- The basement bar sits higher on purpose, to keep you building down there a little longer before the colo opens up.
Seeing where you stand- New Monthly Revenue objective. Your progress toward the next site's revenue target now sits right beside the customer count, instead of being something you had to work out for yourself.
- You get a heads-up the moment you can relocate. No more opening the ops console and checking the Relocate tab to find out the door was already open.
Fixes- The basement no longer starts with a free full-height rack. You move in with the wall cabinet for your carrier handoff and buy your first floor rack yourself, same as the garage.
- The relocation cutover-plan buttons (Rushed, Planned, Phased) had a click area smaller than they looked and were awkward to hit. Fixed.
- Existing garage and basement saves pick up the new gates and balance automatically on load. No new game needed.
- Relocation now unlocks on the size of your business, not the cash in your account. Moving up is a funded relocation that carries your customers and capital forward, so it never costs you liquid cash to make the move. The old cash gates were quietly punishing the players who did the sensible thing and reinvested in hardware, leaving a thriving operation stuck with a full book of customers and an empty wallet. Sites now unlock on monthly revenue instead:
- First update since launch, straight from your feedback: garage pacing and money, CPU contention that was crying wolf, and a batch of placement and console fixes. Keep it coming on Discord: https://discord.gg/V7YVmA2Fux.Read on Steam →Economy and pacing
- The garage now pays properly. Each customer is worth more while you are still in the garage, so the opening funds itself on per-customer revenue instead of forcing you to onboard a crowd. Later sites settle back to the standard rate as your scale grows.
- New customers arrive at a steadier pace in the garage. The intro faucet was running about twice too fast and could bury a garage in dozens of tenants before you had found your feet. It is now paced so the opening builds instead of floods, and the advance-to-basement goal is a milestone you grow into rather than blow past.
Contention and incidents- CPU contention alerts no longer pile up or cry wolf. A "CPU contended" incident now opens only when a host is genuinely over capacity and a customer on it is actually breaching its service level. A host that is busy but keeping up is shown as a state on the host console, not raised as an incident.
- Contention incidents now clear on their own once the host recovers, load drops, or you migrate work off it. Previously they were opened but never resolved, so they accumulated forever.
- Contention severity now reflects real impact (money at risk and service level), not how long the alert has been open. A minor, long-standing contention no longer escalates itself to the top "existential" severity.
- Incident headlines now use the name you gave a server. A renamed host reads as "Server01 CPU contended" instead of "host 27," so you are sent to the box you actually named.
Placement and migration- New workloads now balance across your fleet. New virtual machines are placed on the least-loaded eligible host instead of piling onto the first one that fits, so adding a server actually spreads load onto it rather than new customers landing on an already-busy host.
- You can now migrate a virtual machine onto a host that still has room under its overcommit ceiling. The migration check used to ignore the overcommit dial and measure against raw physical CPU, so it refused hosts that clearly had space to sell.
- A migration that cannot be placed is no longer silent. If there is no host with room (or the target is offline or incompatible), you get a clear message and the machine stays exactly where it was, instead of appearing to move and then snapping back.
Host console- The CPU resource bar now shows live load (actual demand against physical cores) rather than how much is reserved, so a genuinely busy host reads high and a packed-but-idle host reads its real, lower load.
- The workloads list now includes a "Control plane + host services" row. The platform's own CPU use (the control plane and per-host agents) used to be invisible, which made the CPU figure look like it disagreed with the listed workloads.
- The garage now pays properly. Each customer is worth more while you are still in the garage, so the opening funds itself on per-customer revenue instead of forcing you to onboard a crowd. Later sites settle back to the standard rate as your scale grows.
- Read on Steam →Oversubscription
- The capacity fit indicator now responds to your overcommit dial. Comfortable and Tight used to be measured against a host's raw physical CPU, so the dial never moved the reading. It now measures against the sellable, oversubscribed ceiling: turn the dial up and hosts read more comfortable, turn it down and they read tighter.
- Turning the fleet overcommit dial down now rebalances your fleet instead of just changing a number. If lowering the density leaves a host carrying more than its new ceiling allows, the game sheds the excess virtual machines (newest first) onto hosts that have room. If the whole fleet is full there is nowhere to move them, so the over-packed host keeps serving under contention until you free up space.
- The overcommit help now teaches the right thing. Reading up on CPU overselling used to open the unrelated network fabric oversubscription article. There is now a dedicated CPU overcommit explainer, and the "How far can I oversell?" and noisy-neighbour cross-links point to it.
Growth requests- Taking on a customer or an upgrade that would run your fleet oversubscribed now reads clearly. The request shows an "oversubscribed" verdict with a plain recommendation, and overselling is gated behind a soft "Approve anyway" confirmation rather than blocked outright. Overselling is a choice, not a wall.
- A fleet with no free headroom now reads as such in the growth flow, so you can see at a glance when the answer is "buy more hardware" versus "dial up density."
Device consoles- The "Hide down" filter and the per-port "Select for bonding" control on the switch, gateway, and appliance consoles are now real sliding toggles instead of chip buttons.
- The gateway and appliance consoles now have the per-port Select toggle and a visible "Bond ports" button, matching the switch. Marking ports for a bond no longer requires the keyboard.
- The gateway's first tab is now called "Ports" instead of "Uplinks."
- The Threats tab mitigation bar now reads correctly. It is coloured by status (green when protected, amber when absorbing, red when leaking) instead of always showing orange, and an empty bar means nothing is being blocked instead of showing a permanent sliver. The columns were relabelled so they mean what they say: "Residual" is now "Getting through," and "Capacity" is now "Flood budget," the budget for active flood/attack traffic, not a cap on the benign background traffic the box filters for free.
Contention and incidents- CPU contention alerts no longer pile up or cry wolf. A "CPU contended" incident now opens only when a host is genuinely over capacity and a customer on it is actually breaching its service level. A host that is busy but keeping up is shown as a state on the host console, not raised as an incident.
- Contention incidents now clear on their own once the host recovers, load drops, or you migrate work off it. Previously they were opened but never resolved, so they accumulated forever.
- Contention severity now reflects real impact (money at risk and service level), not how long the alert has been open. A minor, long-standing contention no longer escalates itself to the top "existential" severity.
- Incident headlines now use the name you gave a server. A renamed host reads as "Server01 CPU contended" instead of "host 27," so you are sent to the box you actually named.
Placement and migration- New workloads now balance across your fleet. New virtual machines are placed on the least-loaded eligible host instead of piling onto the first one that fits, so adding a server actually spreads load onto it rather than new customers landing on an already-busy host.
- You can now migrate a virtual machine onto a host that still has room under its overcommit ceiling. The migration check used to ignore the overcommit dial and measure against raw physical CPU, so it refused hosts that clearly had space to sell.
- A migration that cannot be placed is no longer silent. If there is no host with room (or the target is offline or incompatible), you get a clear message and the machine stays exactly where it was, instead of appearing to move and then snapping back.
Host console- The CPU resource bar now shows live load (actual demand against physical cores) rather than how much is reserved, so a genuinely busy host reads high and a packed-but-idle host reads its real, lower load.
- The workloads list now includes a "Control plane + host services" row. The platform's own CPU use (the control plane and per-host agents) used to be invisible, which made the CPU figure look like it disagreed with the listed workloads.
- The capacity fit indicator now responds to your overcommit dial. Comfortable and Tight used to be measured against a host's raw physical CPU, so the dial never moved the reading. It now measures against the sellable, oversubscribed ceiling: turn the dial up and hosts read more comfortable, turn it down and they read tighter.
- Read on Steam →Welcome to Early AccessUptime is now in Early Access, and I am glad you're here. Thanks for taking a chance on a game about building a cloud provider from a garage up.
It's early, so expect bugs, rough edges, and balance that needs more work. I'll be fixing them steadily alongside new features, and what you report helps us decide what to fix first.
Found something broken, or have an idea? Join us on Discord to report bugs and tell us what you think: https://discord.gg/V7YVmA2Fux. I read all of it.
Have fun, and go build something.