RunOS Team ·

It's Been a While: What We've Shipped Since 1.0

It’s been a while since we’ve posted. Four months, actually. Sorry about that.

We weren’t quiet because nothing was happening. We were quiet because we were busy, and most of what we built is the kind of thing that’s hard to show off in a screenshot. Access control. BMC networks. Virtual machines. GPU scheduling.

Here’s what’s new.

The short version

RunOS started as a way to run apps on servers you own. It’s still that. But a lot of you asked the same question: what about the servers themselves?

So now RunOS also runs the layer underneath:

  • New RBAC with approvals, hardware keys, and an audit log
  • Bare metal management that talks to your BMCs
  • Virtual machines on KubeVirt, as a VMware replacement
  • Inference pools that keep your GPUs busy
  • Neocloud software: all of the above, plus the pieces you need to rent it to other people

It’s all standard Kubernetes underneath. You still keep your kubeconfig.

New RBAC

A couple of broad roles is fine for a small team. It’s a bad idea once you have people you don’t fully know, or an auditor who does.

The new one has the usual building blocks, and they work the way you’d expect:

  • Roles say what an action is allowed to do
  • Groups hold people, so you stop granting things one user at a time
  • Grants connect a role to a person or group, with conditions and an expiry

Grants that expire are our favorite part. Give someone access for the afternoon, and it’s gone by tonight. Nobody has to remember to clean up. You can also require a stronger sign-in for a grant, up to a hardware key:

runos access grants create --subject person:<id> --role <role> \
  --expires-in 8h --min-assurance hardware

Then there’s the thing we really wanted: approvals. You can mark an action as risky, like reinstalling a server, and require a second person to sign off before it runs. You pick how strongly they have to prove who they are:

  • a password
  • an authenticator code
  • a passkey
  • a hardware key, like a YubiKey

So “reinstall this server” can mean two approvals, each tapped on a security key. Nobody can do it from a stolen session.

Everything lands in the audit log: sign-ins, second-factor changes, role changes, key creation, device approvals, even when RunOS support asks for access to your account. You can read it from the CLI:

runos account audit

There are also periodic access reviews, where someone signs off that the grants still make sense. Boring, and exactly what your auditor will ask for.

One thing that isn’t there yet: SSO. Today, sign-in is password, authenticator, passkey, or hardware key.

Bare metal with BMC management

If you run your own servers, you know the real work starts before the OS. It’s the BMC network: iLO, iDRAC, whatever your vendor calls it.

RunOS now manages that directly. You give it a scan range and BMC credentials, and it does the rest:

  1. Find the machines on your BMC network
  2. Register them
  3. Install from a provisioning profile and a golden image
  4. Control them: power on, power off, reboot, reinstall

There’s also a serial console you can watch live. When SSH is dead and the machine won’t boot, that’s the thing you want.

runos provider servers discover --cid <cid> --range 10.0.0.0/24
runos provider servers start-serial-console <sid>

You can drive all of it from the CLI, the REST API, or MCP. Pick whichever you like.

VMs on KubeVirt

This one is the big one for anyone staring at a VMware renewal quote.

KubeVirt is a CNCF Incubating project that runs virtual machines on Kubernetes. We’ve built it into RunOS, so any bare-metal server you opt in can run one VM or fifty. Kubernetes is the control plane.

What you get:

  • Live migration. Move a running VM to another node with no downtime.
  • VM groups. Each group has its own quota and a default-deny firewall, so one team’s VMs don’t wander into another’s.
  • Snapshots and images. Capture a VM and start new ones from it.
  • Console access. SSH, serial console, and VNC.
  • CPU overcommit you control. Set how many virtual CPUs can share a physical core. Memory is never overcommitted.

Creating one looks like this:

runos vms create --cid <cid> --gid <group> --size <type> \
  --name web-1 --ssh-keys "ssh-ed25519 AAAA..."
runos vms migrate <vmid>

We’re not going to pretend it’s a perfect one-to-one swap for everything vSphere does. Two things to know today. When a host dies, RunOS doesn’t move your VMs on its own: you confirm the host is really powered off, then run runos vms recover to bring each VM back on a surviving machine. And VMs with a GPU attached can’t live-migrate. For plain VM workloads, though, it does the job.

Inference pools

GPUs are expensive when they sit idle. We built a GPU Capacity module so you can decide what each card does.

There are three ways to use a card:

  • On-demand. A VM that is never interrupted.
  • Spot. Cheaper, and it can be stopped. It gets a 120-second warning first, so the guest has time to save its work.
  • Inference. A pool of GPU VMs that serve one model.

An inference pool has a floor and a cap on replicas. The pool sits behind a router, and every request needs an API key. Outside a capacity set, the replica count follows the queue: busy means more replicas, up to your cap.

Inside a capacity set, an arbiter decides which pool gets which card. It follows a few firm rules:

  • It only takes cards from lower-ranked pools
  • It never stops an on-demand VM
  • It never pushes a pool below its floor
  • It checks the whole plan before it stops anything

It starts in dry-run mode, so you can read what it would do before you let it act.

Every GPU-second is metered, at every tier. Which brings us to the last thing.

Neocloud software

Put the pieces together and something interesting happens. You have:

  • servers you can discover, install, and reach through their BMCs
  • VMs and GPUs you can slice up and rent out
  • access control strict enough to hand to someone else
  • metering for every second of GPU use

That’s most of what a small cloud provider runs on. RunOS has a provider and tenant model: you own the hardware, and you allocate machines to your customers’ accounts. They get the same tools you do, including golden images, power control, and the serial console, on their own machines only.

runos provider servers allocate <sid> --tenant-aid <aid>

The usage export gives you one row per period each machine held capacity. RunOS counts the seconds, and your own billing system sets the price. We don’t do your invoicing, on purpose.

If you’re a hosting company, a GPU rental shop, or a team that wants to run its own internal cloud, this is for you.

Try it

There’s a new page that walks through all of this: Infrastructure as a Service.

If you want to see how it fits your setup, tell us what you’ve got. How many servers, what kind, and what you’re running today. We’ll tell you honestly what works and what doesn’t yet.

Talk to us. We read every message.

And we’ll try not to wait four months before the next post.