Codename ███████
A server hosting platform for games and small services, still being built. Billing, provisioning, and a browser console already work; the isolation and pricing model are the current design target, not a finished claim.
- Stripe billing works end to end — payments, coupons, and a customer balance.
- Provisioning a server and getting a noVNC console for it in the browser both work.
- Server lifecycle management works: start, stop, restart, reinstall, backup.
- Aiming for bare metal with NVMe and per-instance isolation instead of oversold shared VMs — that part is design intent, not shipped yet.
- NextJS
- TypeScript
- Drizzle
- Docker
- PVE
- Stripe
Game server hosting is a solved problem in the sense that you can buy it anywhere, and an unsolved one in the sense that most of what you can buy is bad. The failure is almost always the same shape: a box sold four times over, and everyone on it taking turns waiting for the disk.
This is still in development. What's actually working right now: Stripe payments, coupons, and a customer balance; spinning up a server and getting a console to it over noVNC in the browser; and the basic lifecycle actions — start, stop, restart, reinstall, backup. What follows below is the direction I'm building it in, not a list of finished guarantees.
the constraint everything else follows from#
Start from the thing that actually ruins a game server and the rest of the architecture stops being a matter of taste.
It isn't CPU, usually. It's disk latency and a neighbour who decided to recompile something. So the target is bare metal with NVMe rather than oversold shared VMs, one isolated container per instance, and hard CPU and memory limits — not as a fairness policy, but so that somebody else's bad afternoon stays theirs. That part of the architecture isn't built yet; it's the thing the rest of the platform is being built toward.
That decision will cost money once it's in. Overselling is where the margin in this industry comes from, and choosing not to do it means the pricing has to work at real capacity. I'd rather have that constraint than the support queue that comes with the alternative.
provisioning and the console#
Paying and getting a running server with a noVNC console already works. What I haven't proven yet is that it holds on the bad path — during a burst, on a node that's nearly full, when the payment webhook arrives twice. That's the part I'd want working before I'd call provisioning itself done.
why it doesn't have a name yet#
It gets a name when it can take money from someone who isn't me. Naming a thing early is how you end up with a landing page and a waitlist instead of a product, and I'd rather get the boring parts solid first — billing, isolation, the provisioning path — and do the branding once there's something finished behind it.