Enroll your first Compute Node

What "enrolled" means

When the agent paired in the previous chapter, the backend created a row in the devices table with:

• A generated UUID device ID.
• organization_id set from the enrollment key.
• enrollment_status set to APPROVED (auto-approved because a valid key was used — see backend/app/routers/devices/registration/enroll.py).
• status = ONLINE.
• capability_score calculated from the hardware specs the agent reported.
• supports_docker = true, supported_task_types = ["docker"] for desktops; mobile devices get ["wasm"] instead.

That row is what every other part of Zyra — the scheduler, the dashboard, the billing system — uses to reason about your fleet. The rest of this chapter is about making that row meaningful.

Step 1 — Open the device

In the dashboard sidebar, click Compute Nodes and click the row for the device you just paired. The detail page has four tabs: Overview, Settings, Tasks, Logs.

Step 2 — Rename the device

The auto-generated name is the OS hostname plus the platform — e.g., LAPTOP-7H2KQ - win32 or mac-mini-helsinki - darwin. It works but it gets unreadable fast at scale.

Open Settings, click the pencil icon next to the name, and rename to a convention your team can grep. We recommend {role}-{location}-{number}:

• dev-helsinki-01 — a dev workstation in your Helsinki office.
• ci-aws-eu-03 — third CI runner in your EU AWS region.
• gpu-stockholm-01 — a GPU box in Stockholm.

Names must be unique inside your organization. The display value updates immediately across every dashboard view.

Step 3 — Declare capabilities

Hardware was auto-detected from the agent. You decide what's available for Zyra to use, separate from what physically exists. Open Settings → Capabilities:

• Max CPU %. Cap on how much of the CPU Zyra workloads may consume. Default 80%. Set to 50% on machines that double as someone's workstation.
• Max RAM %. Cap on memory. Default 75%.
• GPU exposure. Explicit opt-in. Choose Hidden, Visible to all jobs, or Visible to GPU-tagged jobs only. GPUs are valuable; the default is Hidden so you don't accidentally schedule someone's training run onto a designer's RTX 4090.
• Disk reservation. GB the agent can use for container images and volumes. Default 50 GB.

These caps are enforced by the agent — the Docker runner refuses to start a container that would exceed them — so a misbehaving job cannot starve the host.

Step 4 — Set the availability schedule

Open Settings → Schedule. Pick one of:

• 24/7. Always available. Default for dedicated servers and CI hosts.
• Business hours only. 09:00–18:00 in the device's local timezone, Monday-Friday.
• Off-hours only. Weeknights 19:00-07:00 plus weekends. Useful for opt-in employee laptops.
• Weekends only.
• Custom. A week grid where you click the hours you want available.

When a device is outside its schedule, the agent stays paired but stops accepting new work. Running containers continue until they finish or hit their idle timeout.

Step 5 — Tag the device

Tags are free-form strings used by the scheduler to match workloads to devices. Open Settings → Tags and add a few. Useful patterns:

• tag:gpu if it has an opted-in GPU.
• tag:high-mem for boxes with 64 GB+ RAM.
• tag:windows / tag:macos / tag:linux (often auto-applied; double-check).
• tag:office-helsinki or tag:region-eu for geography.
• tag:pci-zone for devices inside a regulated network segment.

You'll use these in Stage 3 when you create device groups and in Stage 4 when you write placement policies.

Step 6 — Confirm "Ready"

Save the settings. The device's status transitions through:

1. Pairing — agent paired, settings not yet applied.
2. Online — agent is heartbeating, settings applied, idle.
3. Ready (synthesized view) — Online + inside schedule + has capacity. This is the state the scheduler considers when placing work.

What just happened

You converted a paired-but-anonymous machine into a Compute Node the rest of the platform can plan around. The scheduler will now match Virtual Server and job requests against this device's capabilities, schedule, and tags. The billing system will count its uptime against your plan's included quota.

Troubleshooting

• Status stuck on "Pairing". Check the agent log (Windows: %LOCALAPPDATA%\Zyra\logs, macOS: ~/Library/Logs/Zyra Agent/, Linux: ~/.zyra/agent.log). The most common cause is a tight corporate proxy stripping the Authorization header.
• GPU not detected. The agent uses systeminformation's graphics() call; some Linux systems with proprietary NVIDIA drivers need nvidia-smi in PATH for it to enumerate GPUs.
• Capability score lower than expected. Score is computed from CPU cores, RAM, and GPU model with a deterministic formula. A score below 200 usually means a virtualized VM with very few cores; check whether you meant to enroll the host or the VM.