Running games on Ironstake/NovaOS. Honest about performance, drivers, anti-cheat — not a marketing post.
A desktop OS that treats gaming as a first-class workload shapes its kernel, its scheduler, and its anti-cheat posture from the first commit. This is what Ironstake is committed to today, what is honestly still open until the public build ships, and the five-step plan for running your existing library side-by-side when it does.
For readers who want the next step
The full posture is below. The waitlist brief is what follows it.
The full gaming posture is below: the kernel scheduler, the OSS driver model, the anti-cheat contract, and the five-step side-by-side plan. After reading, the next gated step is the waitlist brief — it spells out the launch contract, the dates involved, and which cohort gets the earliest signed image.
Why “real” gaming on a desktop OS still matters
The bar is your existing library, not a curated showcase.
The honest framing: gaming on a desktop OS is a kernel / user-mode scheduler decision first, a launcher decision second, a Steam-deck-style stack never.
“Gaming-ready” on a desktop means the same library that runs on the OS you already use runs on this one — same launcher, same saves, same controller state, same store front. It is not a curated showcase of titles the lab machine happened to bench well. It is the kernel scheduler honouring a vsync deadline while the audio thread, the input thread, and the AI runtime all share the same machine.
That is a kernel / UMS commitment, not a Steam-deck-style stack. The users who care about privacy at the OS layer — the audience for NovaOS — also want their existing library to run. Treating those two requirements as orthogonal is how prior attempts at this market stopped being interesting long before they shipped.
The framing is not “gaming on a privacy OS is a stretch goal.” It is the opposite: the kernel, the scheduler, the driver model, and the anti-cheat posture were chosen to make the existing library run — in a way that does not bleed into the rest of the OS. Everything else follows from that.
What Ironstake is honest about today
Real commitments, a public build date, no marketing mirrors.
Two answers. The first is the commitment. The second is what is still genuinely open.
Committed to
A memory-safe kernel, a native GPU scheduler, no proprietary boot path.
- Memory-safe kernel, drivers, and core services in one codebase — whole exploit classes disappear with the code, not with patching.
- Kernel-side user-mode GPU scheduler designed around the existing launcher model — not a vendor flat-priority scheduler grafted on top.
- Open-source driver model. No proprietary blobs in the boot path. The driver you ship is the driver you can read.
- Telemetry off by default — opt-in is a separate, reversible choice. The data program never reads screen contents, window titles, or keystrokes.
Honest gap
The public build is later in 2026.
Ironstake / NovaOS is not a daily-driver build today. We will not ship a release-date-shaped promise we cannot keep. No curated launch title list is promised either — the coverage map is published when the build is ready, not before. The build ships when it ships; you hear from us the same day it does, on one email.
Driver support + compat coverage
Coverage maps are published when the build is ready, not before.
The honest position on driver support is structural, not a benchmark reel. OS-level scaffolding first; per-game verification later, in the open.
Driver posture, committed to
- Kernel-side user-mode GPU scheduler with fair-share across launchers.
- No proprietary blobs in the boot path — the driver is the code.
- Reverse-engineered driver protocol paths where the vendor path is restricted, documented in the open.
- Same memory-safety model in drivers as in the kernel.
Honest gap · not there yet
- No per-game compatibility sheet today — the coverage map is published when the build is ready, not before.
- Hardware compatibility list not finalised — it needs installs in the wild before it can be written honestly.
- No day-one claim of “every Steam title runs” — the kernel posture is committed to, raw coverage is not.
- Vendor-specific optimisations (vendor-level frame pacing, vendor AI upscaling) absent by design — the user-mode-side is the user’s choice.
Performance posture
Memory-safe ≠ slow. The wins are in the scheduler, not the benchmark reel.
The performance posture is structural: the kernel scheduler, the user-mode GPU scheduler, and the dispatch path are designed as one system. The benchmark reel is not the commitment. The architectural conditions are.
Performance, committed to
- No compositor-induced frame drops — the display path is engineered to hold a deadline under load.
- No data-center round trip on the inference path — the AI runtime lives next to the window it serves.
- No idle-bandwidth tax — telemetry is off, no background call-home, the network stays quiet when the user does.
- Fair-share scheduling across launchers — one launcher cannot starve another’s frame path at the kernel level.
Honest gap · what first-boot will look like
- First-boot will have a cold-path effect for some titles — shader caches rebuild, per-launcher caches rebuild, the second boot is the “real” one.
- Per-frame parity with vendor reference stacks is not promised on day-1 — it is the direction, not the line in the sand.
- AI upscaling paths via vendor SDKs are not in the boot path; if you want them, they will live above the OS, not inside it.
- No published benchmark number as the headline figure — the architectural commitments are the headline.
Anti-cheat posture
The contract you can hold us to — what we will and will not do.
Anti-cheat is the part of the gaming posture that most needs to be written down in advance. This is the list.
Committed to anti-cheat posture
- Kernel-level integrity checks — only against the running game process boundary.
- Ring-0 user-mode inspection of the game process, signed kernel modules, and authorised anti-cheat clients.
- Telemetry scoped to the player session ID — not screen contents, not per-action logs, not your machine’s broader state.
- Anti-cheat code paths open, with the boundary they operate inside documented before they ship.
What anti-cheat will never depend on
- Never contents-of-window inspection — no pixels out of any other process ever.
- Never keystroke capture beyond the game process boundary — the anti-cheat client does not see outside the running game.
- Never per-frame screen content — not at first boot, not on opt-in, not ever.
- Never exfiltrating telemetry tied to a desktop session beyond the anti-cheat’s own consent surface.
Setup steps today
Five steps, a free evening, your existing library runs side-by-side.
The flow below is what the experience looks like when the public build ships. A free evening, a single rebooted machine, your existing Steam / launcher / library fully intact on the same disk.
- 01Download the signed image. The same one everyone else downloads — no registrar, no account, no telemetry opt-in dialog.
- 02Flash it to a USB stick. Side-by-side install keeps your existing OS as a selectable entry in the boot menu — not deleted, not modified, not contacted.
- 03Boot. Point the launcher at your existing Steam / library paths — the install on the other partition is the same path, the saves are the same files, no migration step required.
- 04First-boot setup runs. Pick a username, pick a theme, opt in or decline the data program. Reversible from settings at any time, same toggle either way.
- 05Launch. Your existing library runs in the side-by-side partition. Nothing about it has been touched — no DRM handshake rerun, no client re-installed, no save folder moved.
The default commitment: nothing about your existing install or library is touched at first boot. The two operating systems share a disk and a boot menu; they do not share state, and the new one does not phone home about the old one.
Head to the Downloads dashboard →
Signed-in readers have early access to the build images already published for the waitlist cohort.