Provider Landscape

Read when:

• comparing Crabbox with adjacent sandbox, dev-environment, or microVM tools;
• deciding whether a competitor should become a first-class provider;
• planning provider capability work without live provider credentials.

This is a product and architecture map, not a benchmark. External products move quickly, so use this page to decide the next Crabbox seam to harden, then verify current behavior against the provider docs before adding code.

#Core Position

Crabbox should own the provider-neutral contract: selecting a target, syncing a checkout, running commands, returning proof, exposing reachability, and cleaning up capacity. It should not copy every adjacent product's control plane.

That means:

• support stable execution substrates as providers;
• expose shared workflow capabilities through crabbox providers and

crabbox providers recommend;

• keep runtime-shape labels provider-neutral (managed-sandbox,

delegated-command, ssh-host, worker-module) instead of copying one vendor's control-plane terms;

• keep reachability labels provider-neutral (provider-url, ssh-tunnel,

tailnet-peer, tailnet-egress) so preview URL, tailnet, and SSH tunnel workflows can be compared without provider-specific docs scraping;

• use ssh or external for tools that already produce a normal host contract;
• defer first-class support for runtimes whose useful behavior is still too

product-specific to test offline.

#Landscape

#Mitos Decision

Do not add first-class Mitos support yet.

Mitos is strategically interesting because it targets forkable Firecracker microVM swarms, MCP, and copy-on-write fan-out from a warm running machine. That is a different contract from most Crabbox providers. If Crabbox adds mitos today, the likely failure mode is ugly: Mitos-specific flags, Kubernetes and KVM assumptions leaking into core, and tests that cannot prove the useful behavior without a live cluster.

The better path is to make the generic seams real first:

• workspace-checkpoint, workspace-fork, workspace-restore, and

provider-snapshot keep forkable workspace language provider-neutral.

• runtime filter values like managed-sandbox, delegated-command, and

worker-module describe the execution shape without implying Mitos-style live microVM forking.

• mcp-attachments stays a capability, not a Mitos-only command mode.
• run-proof, run-artifacts, run-downloads, and url-bridge keep evidence

portable across delegated sandboxes and proof runners.

• lifecycle filter values like cleanup, pause-resume, run-session,

workspace-state, and coordinator-governed expose stateful sandbox and devbox controls without baking in one provider's lifecycle API.

• reachability filter values describe access planes without claiming a

provider-specific network isolation model.

• remote-dev, mcp-sandbox, isolated-execution, and

versioned-workspace keep recommendations workflow-oriented.

• fanout-testing and its best-of-n alias route operators to existing

fork-capable providers without adding a Mitos-only live-fork API.

• checkpoint fork --count covers ordinary parallel attempts against archive

and native checkpoints while keeping live memory-forking as a future provider optimization, not a core CLI assumption.

Revisit Mitos only when there is a concrete use case that needs live microVM forking and the provider contract can be tested with offline unit coverage plus an opt-in live smoke. Until then, document it as an observed adjacent system.

#Support Matrix

#Roadmap

Ship these in small PRs:

1. Keep recommendation surfaces workflow-first.

ci-proof, run-evidence, fast-feedback, isolated-execution, mcp-sandbox, remote-dev, team-cloud, and versioned-workspace should stay the public routing vocabulary.

2. Improve evidence parity for delegated sandboxes.

The biggest practical gap versus hosted sandbox products is not launch; it is consistent proof, artifacts, downloads, preview URLs, logs, and error status. Use crabbox providers recommend run-session when the workflow needs a reusable provider session handle for later inspection. Use crabbox providers recommend artifact-download when a workflow needs retained files or downloadable results from provider-owned execution. Use crabbox providers recommend failure-diagnostics when failed-run triage needs proof, reusable sessions, retained outputs, preview URLs, or SSH access to a synced checkout. Use crabbox providers recommend interactive-debug when triage needs a live inspection surface such as synced SSH, browser/code/desktop access, reusable sessions, provider URLs, or retained evidence after the debug session. Use crabbox providers recommend preview-url when the workflow specifically needs provider-native app or service URLs. Use crabbox providers --reachability provider-url or crabbox providers recommend reachability --reachability tailnet-peer when the operator needs an explicit access plane. Use crabbox providers recommend network-isolation when the workflow runs untrusted code and network exposure should stay inside a delegated or local sandbox boundary. Use crabbox providers recommend resource-observability when the workflow needs coordinator usage/cost visibility, SSH resource telemetry, retained run evidence, reusable sessions, or preview URLs for later inspection. Use crabbox providers recommend code-interpreter when generated-code or script execution should prefer delegated or local sandboxes with sessions, archive sync, retained outputs, preview URLs, MCP attachments, or module execution. Use crabbox providers recommend disposable-execution when temporary workloads should prefer cleanup-capable delegated or local sandboxes before retaining only the proof, outputs, session, or preview metadata needed for inspection. Use crabbox providers recommend web-app-smoke when app or service smoke tests need provider-native URLs, SSH tunnels, tailnet reachability, browser/code/desktop access, sessions, or retained outputs.

3. Add live smoke docs where credentials are required.

Provider adapters can be valuable before broad live access exists, but each one needs an opt-in smoke contract that says what real behavior proves. See Provider live smoke for the shared contract. Use crabbox providers recommend live-smoke to pick candidates from offline lifecycle, sync, cleanup, and evidence metadata before spending capacity. Use crabbox providers recommend cost-control when a workflow should prefer local runtimes, coordinator governance, cleanup, cache reuse, or retained proof before spending provider quota. Use crabbox providers recommend offline-validation when live provider credentials or quota are not available yet; it prefers local runtimes, local sandboxes/VMs, BYO SSH hosts, and external-provider contracts over cloud API-backed leases. Use crabbox providers recommend pause-resume when long-running sandbox or dev-environment state needs to be parked and resumed. Use crabbox providers recommend warm-start when repeated runs should prefer local runtimes, reusable caches, retained sessions, pause/resume, or workspace-state signals before paying remote cold-start cost.

4. Strengthen workspace reuse before runtime-specific forking.

Checkpoint, fork, restore, and provider snapshot semantics should be testable through the CLI before adding live microVM fan-out. Use crabbox providers recommend workspace-reuse as the workflow entry point when the operator cares about reusable state more than a specific fork API. Use crabbox providers recommend fanout-testing when the workflow needs parallel branch or best-of-N experimentation from forkable state.

5. Keep edge/worker execution separate from Linux sandboxes.

A Worker module runtime is not the same thing as a Linux shell. Make the target and feature names say that clearly.

#Add-Provider Bar

Add a first-class provider when the PR can prove:

• stable lifecycle: create, inspect, run or attach, release, cleanup;
• honest ProviderSpec.Kind, category, targets, and feature flags;
• documented auth from env/config, never command-line secrets;
• offline tests for parsing, command construction, status/list rendering, and

provider errors;

• opt-in live smoke when credentials or quota are required;
• docs that explain when to use the provider and when to choose an existing

workflow instead.

If the bar is not met, use ssh or external and document the manual contract.