Supported platforms
Linux and macOS run natively. Windows is supported virtualized — the server as a container, agent machines as Linux containers or Linux virtual machines.
There are two things to place on a platform, and they are placed separately: the server — the control plane that holds the record and drives the work — and the agent machines the server dispatches onto.
| platform | the server | agent machines |
|---|---|---|
| Linux (x86-64, ARM64) | natively | natively, as container images, or as Linux virtual machines |
| macOS (Apple silicon) | natively | natively, or as Linux containers and virtual machines |
| Windows | as a container image | Linux, virtualized — container images or Linux virtual machines |
⇒ Container images are a first-class form of agent machine on every platform, not a Windows workaround: they are the shape the Team and Enterprise postures use, and the product ships a template per language class. See Agent machines.
⚠ Windows is supported virtualized, not natively. There is no native Windows build of either half, and none is planned. What is supported is a Windows host running Linux underneath: the server as a container image, and each agent machine as a Linux container or a Linux virtual machine. ⇒ This is a documented deployment shape, not a workaround — a Windows estate runs the product the same way it runs other Linux-based server software.
What a Windows deployment actually looks like
- The server runs as a container on the Windows host, with your datastore reachable from it.
- Agent machines are Linux — you choose the form: container images, if you want them disposable and identical (the product ships a template per language class), or Linux virtual machines, if you want longer-lived machines that match how you already manage capacity. Both are supported, and a fleet may mix them.
- Everything above that layer is identical to a Linux or macOS install: the same streams, the same roles and seats, the same gates, the same record. ⇒ Nothing in the product's surface is Windows-specific, and nothing is withheld on Windows.
⚠ What this makes a prerequisite: on Windows, a container runtime or a hypervisor is part of the installation rather than an optional convenience. Choose one before you start — see Deployment.
Why virtualized rather than native
The controls this product places around an agent session — what it may write, what it may reach — rest on the confinement facilities that Linux and macOS provide, and each is measured per platform rather than assumed. ⇒ Running agents on Linux, virtualized, gives a Windows estate the same boundary as a Linux estate, described by the same pages. A native Windows build would need its own confinement story before any of it could be stated in writing.
See Sandboxing for what confinement each platform offers.
Agent machines can be a mix
The server's platform does not constrain the machines it drives, and neither does their form. A fleet routinely runs host machines, container images and virtual machines at once — Linux beside macOS — each in its own seat, under the same streams, the same gates and the same ledger. A Windows-hosted server drives that same mix. ⚠ What differs per machine is the confinement available to a session there, which is measured on the machine rather than inferred from its platform.