Skip to content
Rigs vs AWS WorkSpaces

Rigs vs AWS WorkSpaces

WorkSpaces is built for persistent, per-employee virtual desktops managed through AWS and Active Directory. Rigs is built for programmable desktop sessions — provisioned by API or agent, governed per tenant, metered per minute.

The matrix

Dimension by dimension.

Checks mark the stronger side; dashes mark a genuine tie.

DimensionRigsAWS WorkSpaces
OS coverage
macOS, Windows, and Linux (XFCE/KDE) from one API
Windows and Amazon Linux/Ubuntu. No macOS.
Agent control surfaces
MCP server, typed SDK, REST — agents are first-class principals
No agent-native surface; APIs target fleet administration
Provisioning speed
Sessions queue on Omega in seconds
New WorkSpaces typically take tens of minutes to provision
Governance model
Keystone tenant scoping, OAuth scopes per capability, short-lived credentials
Mature AD/IAM integration; deep directory and device policy controls
Pricing model
Per-minute by OS and size; headless Linux at a fraction of visual
Monthly per-desktop bundles or hourly with a monthly floor
Persistent employee desktops
Persistent variant exists, but Rigs optimizes for sessions
Purpose-built: user volumes, directory join, image management at fleet scale
Candor

When to choose which.

AWS WorkSpaces is a serious product. Here is where it genuinely beats us — and where Rigs is the obvious call.

Choose WorkSpaces when…

  • You are provisioning long-lived desktops for a large workforce inside an AWS + Active Directory estate.
  • You need Microsoft 365 licensing arrangements and device policy via existing directory tooling.
  • Your users keep one desktop for months and never touch an API.

Choose Rigs when…

  • Your desktops are created and destroyed by software — CI jobs, computer-use agents, ephemeral operator sessions.
  • You need macOS, Windows, and Linux behind one API instead of one vendor per OS.
  • You want per-minute metering and tenant-scoped governance rather than per-user monthly bundles.
Migration

If you decide to move.

A migration is a mapping exercise, not a rewrite. The three moves that matter:

  1. 01

    Map each WorkSpaces bundle to a Rigs OS image and size; persistent users map to the persistent variant.

  2. 02

    Replace directory-driven entitlement with Keystone scopes (rigs:instances:create, rigs:instances:control).

  3. 03

    Move automation from the WorkSpaces admin API to the Rigs REST API or TypeScript SDK — list, create, action, term.

Your fleet is one provision call away.

Open the console and spin a governed desktop in seconds — or talk to us about running your whole fleet on Rigs.

npx @l1fe/rigs-mcp — for the agents in the room