Setup and operating system support

Matrix

Six rows, one decision: which class does your machine fall into?

The support class determines both which jobs you get and where you stand in placement. The table below summarizes the decision; the list right under it explains the reason for each row.

Operating system	Status	Job type	Scorecard impact	Note
Linux + NVIDIA Ubuntu 22.04 / 24.04, Debian 12 · x86_64	First class — full support	All job types, long training included	No ceiling; all four metrics count at full weight	Single static Go binary; driver 535+
Windows + NVIDIA (WSL2) Windows 10 22H2 / 11 · WSL2 + Ubuntu	Second class — limited	Short, interruptible jobs: image generation, batch inference	Reboots lower uptime; at an equal score it is placed behind Linux	The driver stays on Windows, the agent runs inside WSL2
Windows — without WSL2	Not supported	—	—	GPU passthrough in Windows containers does not meet our model
macOS Apple Silicon and Intel + eGPU	Not supported	—	—	No CUDA; passing the GPU into a container is not possible
AMD ROCm · Intel Arc	Not supported — to be revisited	—	—	The overwhelming majority of customer workloads depend on CUDA
GPU passthrough inside a VM	Not supported	—	—	Hardware verification cannot be done reliably

The "Scorecard impact" column is a design decision, not a measured result: the placement algorithm ships with these rules in Phase 1. Metric weights: Scorecard.

The reason behind every row

Linux is first class because the whole stack lives there

The agent is a single static Go binary; it talks to containerd, passes the card into the container with the NVIDIA Container Toolkit, reads telemetry straight from the driver through go-nvml, and builds its tunnel with WireGuard. All four of those components are first class on Linux. No intermediate layer sits between the number we measure and the reality of the card.

Windows is second class because there is a layer in between

WSL2 runs a real Linux kernel and, thanks to CUDA on WSL, the card is visible. But I/O goes through a virtual disk, pinned memory adds overhead, and on multi-card machines the P2P/NVLink expectation is not met. In a long training job these differences add up; in a short inference job they are usually invisible. That is why Windows machines are placed in the short-job pool.

Windows without WSL2 is out because the isolation model doesn't hold

We run customer workloads in Linux containers; images are signed and secrets never touch the host disk. There is no equivalent on the Windows side: running the workload as a native process breaks the guarantee that "customer secrets never touch the host disk". Without WSL2 we cannot give that guarantee, so we don't list the machine.

macOS is out because there is no CUDA and the GPU doesn't enter a container

Two separate reasons lead to the same conclusion. First: the overwhelming majority of customer workloads depend on CUDA, and a card running through Metal/MLX does not answer that demand. Second: on macOS you cannot pass the GPU into a container — Docker Desktop does not grant Metal access, and running natively does not meet our isolation promise. Intel Mac + eGPU is a dead end: eGPU support is at the end of its road in modern macOS releases.

AMD and Intel are absent today, but not closed for tomorrow

ROCm and oneAPI are improving, but the images, kernels and libraries on the customer side still assume CUDA. Supporting them would open a supply class full of workloads that don't run — bad for the host and for the customer alike. When the demand becomes concrete, we will look again with a separate image pipeline.

GPUs inside a VM are out because they can't be verified

The scorecard system rests on hardware verification: card identity, driver version, thermal and power telemetry. A virtual machine layer clips those values or makes them spoofable. We do not list hardware we cannot verify as "this card is present".

First class

Linux + NVIDIA: one binary, one line, full support.

Supported distributions are Ubuntu 22.04 LTS, Ubuntu 24.04 LTS and Debian 12; architecture x86_64; NVIDIA driver 535 or newer. Installation is a one-line command and a single-use enrollment token.

No inbound port: the agent always establishes the connection outbound. No port forwarding, no static IP, no firewall hole — it works behind NAT and CGNAT too, and you never touch the router.

You install no dependencies: the agent takes care of containerd and the NVIDIA Container Toolkit. The only thing you need is a working driver.

All job types: including training runs that last for days. On a multi-card machine, P2P and NVLink are used as they are.

It runs as a service: installed as a systemd unit, it comes back on its own when the machine reboots and keeps reporting from where it left off.

Get the enrollment token

You define the machine in the host panel and a single-use enrollment token is generated. The token is the only secret that binds the machine to your account; copy it and share it with nobody.

Run the one-liner

The command downloads the agent, installs it as a systemd service and enrolls with the token. No listening port is opened on your machine during setup.

Verification, benchmark, price

The agent reports the cards, CPU/RAM and network speed, then runs the first benchmark. At the end you see a price suggestion based on the regional median — accept it or write your own price.

linuxubuntu 22.04 / 24.04debian 12

# One line: downloads the agent, installs it as a systemd service
$ curl -fsSL https://get.kaldera.ai | sh
agent installed · systemd service enabled

# Bind the machine to your account — token comes from the panel
$ kaldera-agent enroll --token KLD-ENROLL-XXXX
verifying hardware... 4× RTX 4090 · 24 GB
driver 550.xx · containerd + NVIDIA toolkit ready
measuring network... median bandwidth recorded
running first benchmark...
✓ machine listed · no inbound port opened

# When you want the machine back
$ kaldera-agent drain
no new jobs accepted; frees up when the current pod ends

Second class

Windows + NVIDIA: works through WSL2, takes short jobs.

The NVIDIA driver stays on the Windows side; the agent runs inside the Linux distribution in WSL2 (CUDA on WSL). The agent is also installed as a Windows service and manages the WSL2 distribution: it brings the distribution up when the machine boots and back up when it falls over.

How it works

The Windows driver is exposed to WSL under /usr/lib/wsl/lib. Containers run on containerd inside WSL2 and the card is passed through with the NVIDIA Container Toolkit. The isolation model is the same as on Linux: customer secrets never touch the host disk.

What you install

Two pieces: WSL2 + an Ubuntu distribution (once) and the agent (inside the distribution). The Windows service keeps the distribution alive. No port is opened to the outside on the Windows side either; the connection is again outbound.

Honest limits

We write these up front so you don't discover them after installing. None of them are hidden, and all of them are measurable.

Windows updates restart the machine. Every unplanned restart is written to the uptime metric and your scorecard drops. Setting active hours helps, but it does not end the problem.

The WSL layer adds overhead. Disk I/O goes through a virtual disk and pinned memory is more expensive. On multi-card machines P2P/NVLink should not be expected — multi-GPU training does not give correct results on this path.

The typical Windows host is a gaming PC. One card, a consumer connection, and an owner using the same machine. Put those three together and what comes out is not a machine suited to long jobs.

That is why you get short, interruptible jobs: image generation, batch inference, short evaluation runs. A training job that will run for days does not go to a Windows machine.

You place behind Linux machines. This is not a penalty, it is job fit: at the same card, the same price and the same scorecard, long jobs go to Linux and short jobs come to you.

Preparation

WSL2 preparation: three commands, one check.

Keep the driver current on Windows

No separate driver is installed for WSL — installing a Linux driver inside the distribution breaks the setup. Just keep the NVIDIA driver on Windows at 535 or newer. That's all.

Install WSL2 and Ubuntu

One command in an administrator PowerShell is enough. You may need to restart the machine once after installation.

Verify the card is visible from inside WSL

If nvidia-smi lists the card inside the distribution, the path is clear. If it doesn't, do not install the agent; solve this step first.

Install the agent inside the distribution

The same one-line command, with --profile wsl2 appended. The profile tells the control plane that the machine will be placed in the short-job pool and that Windows restarts are an expected event.

windows · wsl2powershellprofile: wsl2

# Administrator PowerShell — WSL2 + Ubuntu (once)
PS> wsl --install -d Ubuntu-24.04
PS> wsl --set-default-version 2

# The driver stays on Windows; it must be visible from WSL
PS> wsl -d Ubuntu-24.04 -- nvidia-smi
NVIDIA-SMI 550.xx · CUDA 12.4 · RTX 4080 SUPER

# The agent is installed inside the distribution
$ curl -fsSL https://get.kaldera.ai | sh
$ kaldera-agent enroll --token KLD-ENROLL-XXXX \
    --profile wsl2
profile: wsl2 · short-job pool
windows service installed · distribution supervised
✓ machine listed · no inbound port opened

The WSL2 profile ships in Phase 1. The commands above are there to describe the flow; there is no agent to download today.

Alternative

You're on Windows and you want serious earnings: boot Linux from a second disk.

We are not hiding this advice, because this is what changes the number. Same hardware, same card, same electricity — but first-class support, access to long jobs and a full place in the queue. It is done without touching your Windows installation.

Install on a separate disk, leave Windows alone

A second SSD, an external NVMe or a fast USB disk is enough. You don't need to partition the Windows disk; the two systems sit unaware of each other. The day you want your card back, you boot into Windows. That's it.

Install Ubuntu 24.04 LTS, install the driver

Desktop or server edition, it makes no difference. Once the NVIDIA driver 535+ is installed, if nvidia-smi sees the card, you are ready.

Install the agent, enroll without a profile

The same one-line command. This time there is no --profile wsl2: the machine is listed as first class.

Set up a usage schedule

If you want to game by day and host at night, you boot the two systems in turn. Or you leave the machine on Linux entirely and define a maintenance window; a scheduled window does not lower the scorecard.

What you gain

Access to long training jobs, full telemetry, P2P/NVLink on a multi-card machine, priority placement at an equal score, and an uptime metric that doesn't fall because of a Windows update.

What you lose

Convenience. Switching between the two systems is a reboot, not a click. If you want to use the machine as a gaming PC and a host at the same time, the WSL2 path is more comfortable — but the earnings ceiling is lower.

macOS

Not supported. The reason is technical and clear.

No CUDA, and the demand is in CUDA

Apple Silicon has Metal and MLX; they work well. But the overwhelming majority of customer workloads depend on CUDA: images, kernels and libraries assume CUDA. Listing these cards would create a supply class that could run almost none of the incoming jobs.

The GPU doesn't enter a container

On macOS you cannot pass the GPU into a container — Docker Desktop does not grant Metal access. What remains is running the workload as a native process, and that does not satisfy the guarantee that customer secrets never touch the host disk. Without our isolation model you cannot be a host.

Intel Mac + eGPU: a dead end

It was possible for a while; it isn't any more. In modern macOS releases eGPU support is at the end of its road, and there has been no NVIDIA driver for years. You don't build a product on that path.

Later: it could be a separate supply class

The large unified memory of M-series Max/Ultra parts is genuinely interesting for low-power LLM inference. But that is not one more row added to the CUDA pool: it means a separate product, a separate image pipeline and a separate isolation model. It doesn't exist today, and we are not promising it.

Tell me if Apple Silicon opens

No form, no list: the email is there so we can write to you directly. The address is a placeholder; this page will be updated when it goes live.

Operating system support: who is first class, who isn't