v0.1.17 (Early Access)

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.

Fixes

Networking & 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).