# machine

One ready-to-work Linux machine per project.

Source: https://wheredoirunthis.com/products/machine · JSON: https://wheredoirunthis.com/api/products/machine · Read on 2026-09-25

## At a glance

- Type: Persistent environment
- Kind: Open source tool
- Isolation: Virtual machine
- Free tier: Not documented
- Starting price: Not disclosed
- GPU: No
- Regions: Not disclosed
- Coverage: 6 of 55 assessed capabilities supported · 6 not assessed
- Agent readiness: read 5 of 10 signals, drive 1 of 9 signals

## Links

- Homepage: https://runmachine.dev/
- Docs: https://runmachine.dev/docs/
- Repository: https://github.com/katspaugh/machine

## Runtime

- **GPU & accelerators**: No — "No GPU provisioning/passthrough advertised. Lima `vz` VMs on a Mac; any GPU is a property of the operator's own machine, not a `machine` facet. Not offered." (source: docs (no GPU mention)) (confidence: medium)
- **BYOC (Bring your own cloud)**: na — "na for a self-host OSS tool — `machine` runs entirely on YOUR own Mac by definition (covered by self-host-oss). BYOC as a managed-service 'deploy into your cloud account' concept does not apply." (source: self-host model) (confidence: high)
- **Secrets management**: First-class tmpfs-only secrets. `machine secrets [p]` renders 1Password Environment(s) into VM tmpfs ($XDG_RUNTIME_DIR/dev-secrets) — 'wiped at shutdown'; `--clear` wipes them. Git identity + signing key flow in as Lima `--set` params and render into ~/.gitconfig; signing-key resolution has a documented precedence (GIT_SIGNING_KEY / OP_SIGNING_KEY_REF via `op read` / GIT_SIGNING_PUBKEY_FILE / host git config). — "'Secrets from 1Password land in $XDG_RUNTIME_DIR/dev-secrets, a tmpfs that's wiped at shutdown.' `machine secrets [p] [--repo <r>]`: 'Render 1Password Environment(s) into VM tmpfs.'" [source](https://runmachine.dev/docs/) (confidence: high)
- **Storage options**: Per-project qcow2 VM disk (default 30 GiB; per-project cpus/memory/disk override in projects.toml / .machine.toml). A baked base disk cached in ~/.cache/machine. No host filesystem mount (Lima mountType disabled). Repos clone to ~/code/<repo>/ inside the guest. — "Example config `disk = "60GiB"`, default 'disk 30G'; 'The first `up` bakes a provisioned base disk into ~/.cache/machine.' 'Lima's default mountType is disabled. The VM can't read your ~/ or anything else.'" [source](https://runmachine.dev/docs/) (confidence: high)
- **Supported workloads**: per-project-dev-environments, sandboxed-coding-agent-sessions, docker-workloads, node-js-development, browser-testing (cypress/playwright profiles), supabase-fly-development — "'Docker, Node, agent CLIs (Claude Code, Codex), GitHub CLI, signed git, and opt-in tool profiles (Cypress, Playwright, Supabase + flyctl, modern CLI tools).' Each project gets 'its own filesystem, tools, services, ports, secrets, and agent sessions.'" [source](https://runmachine.dev/) (confidence: high)
- **Persistence**: Durable per-project VM. Each project's Lima VM has its own qcow2 disk (default 30 GiB, configurable per project); `machine down` STOPS the VM but PRESERVES the disk (re-provision in place with `machine up`), and `machine destroy` deletes it. A provisioned base disk is baked once into ~/.cache/machine and reused. Not ephemeral — 'your projects come back as machines.' No host filesystem is mounted (Lima's default mountType is disabled). — "`machine down [p]`: 'Stop the VM (preserves disk). Re-provision in place with `machine up [p]` afterwards.' `machine destroy [p]`: 'Delete the VM.' 'The first `up` bakes a provisioned base disk into ~/.cache/machine ... subsequent boots reuse it.'" [source](https://runmachine.dev/docs/) (confidence: high)
- **Data jurisdiction**: na — "na — the VM runs on the operator's own Mac; there is no product-operated region or data-residency concept." (source: self-host model) (confidence: high)
- **Resource limits & quotas**: Operator-bounded — limited by your Mac's CPU/memory/disk. Per-VM resources are declared per project (defaults: 4 CPUs / 8 GiB memory / 30 GiB disk; a heavy monorepo can set more, e.g. 8 CPUs / 16 GiB / 60 GiB). No product-imposed SaaS quotas. — "'A heavy monorepo gets more than the default 4 CPUs / 8GiB / 30GiB disk'; per-project `cpus`/`memory`/`disk` keys. Changing VM resources requires a recreate (fixed at create time)." [source](https://runmachine.dev/docs/) (confidence: high)
- **SDK languages**: Not documented — "No client SDK library — the interface is the `machine` CLI plus declarative Lima templates / `projects.toml` / `.machine.toml` config. No programmatic API." (source: docs) (confidence: high)
- **Network & egress controls**: VMs get outbound network via Lima's default NAT; Lima auto-forwards any LISTENING guest port to 127.0.0.1 on the host. INBOUND host access is tightly restricted (no host filesystem mount; forwarded SSH agent keys can be used but not read; tmpfs secrets), but NO configurable egress firewall / allowlist / outbound policy is exposed. — "'Lima auto-forwards any listening guest port to 127.0.0.1 on the host.' Security posture is isolation-of-the-host (no fs mount, tmpfs secrets, agent-forward-not-copy), not configurable egress policy on the guest." [source](https://runmachine.dev/docs/) (confidence: high)
- **Snapshots & forks**: A provisioned base disk is BAKED once (`machine bake`) into ~/.cache/machine and prepended as the top-priority image for every project VM — a golden base image that per-project VMs layer on (a fork-from-base pattern). But there is NO user-facing snapshot / restore / clone of a RUNNING VM; 'to start truly fresh: `machine destroy && machine up`.' — "`machine bake`: 'Build/refresh the cached base disk in ~/.cache/machine used by `up`. --force rebuilds even if the cache hash is fresh.' 'the cached base disk prepended as the top-priority image.' No live-VM snapshot command." [source](https://runmachine.dev/docs/) (confidence: medium)
- **Deployment methods**: cli — "The `machine` CLI is the sole interface (`up`/`create`/`ssh`/`claude`/`run`/`down`/`destroy`/`bake`/`secrets`/`init`/`doctor`); workloads (VMs) are declared as version-controlled Lima templates + provision scripts composed via Lima's `base:` mechanism, and per-project config in `projects.toml` / a repo-local `.machine.toml`." [source](https://runmachine.dev/docs/) (confidence: high)
- **Isolation**: Virtual machine — "'Lima boots one Linux VM per project'; 'hypervisor: Lima — Apple Virtualization · vz'; 'no host fs mount', 'tmpfs secrets', '— isolation barrier —'. VMs boot through Lima's `vz` driver (Apple's Virtualization framework) with an Ubuntu 24.04 guest kernel; the sandboxing guide's comparison table lists machine's isolation boundary as a full VM (own kernel), 'Same isolation class' as Tart and Apple's `container` (both Virtualization framework), and STRONGER than a devcontainer ('Kernel namespaces; host kernel shared'). No dedicated isolationEnum value for Apple Virtualization → `vm` is the correct strong-isolation code (own-kernel VM, hypervisor is Apple's vz)." (source: homepage 'architecture' + docs Install + sandboxing guide comparison) (confidence: high)

## Capabilities

### AI & agents

| Capability | Status | Evidence |
| --- | --- | --- |
| Agent skills | Not supported | "No `machine` agent-skills/tools primitive. The enabled Claude Code plugins (superpowers, frontend-design, ...) belong to the Claude Code agent, configured by `machine`, not a `machine` skills primitive." [source](https://runmachine.dev/) |
| AI app builder | Not supported | "No prompt-to-app / vibe-coding generation surface." [source](https://runmachine.dev/) |
| Autonomous QA agent | Not supported | "No first-party autonomous QA/testing agent (you could run one via the pre-installed agents, but it is not shipped as a feature)." [source](https://runmachine.dev/) |
| Built-in coding agent | Partially supported | "Ships + pre-wires coding agents (Claude Code with the official marketplace + a curated plugin set + auto permission mode; Codex in the base image; `machine claude`), but they are THIRD-PARTY agents, not a first-party `machine` agent." [source](https://runmachine.dev/) |
| BYOK for LLMs | Not supported | "`machine` has no LLM-provider-key concept of its own — you authenticate the pre-installed Claude Code / Codex yourself. (Generic secrets via 1Password could hold an API key, but that is not an advertised BYOK-LLM facet.)" [source](https://runmachine.dev/) |
| Credential-injection proxy | Partially supported | "SSH private keys only: 'Private keys never leave the host and the VM cannot read them — but it can *use* them' (forwarded ssh-agent brokers signing/auth from outside the VM). API/app secrets are NOT proxied: `machine secrets` 'pipes the rendered KEY=value pairs into the VM' tmpfs, so the workload holds them; no on-the-wire placeholder swap for HTTP credentials." [source](https://github.com/katspaugh/machine#threat-model) |
| LLM gateway | Not supported | "No multi-provider LLM gateway/router; the pre-installed agents use your own credentials directly." [source](https://runmachine.dev/) |
| MCP client | Not supported | "`machine` itself is not an MCP client (the Claude Code / Codex agents it pre-installs may be, but that is not a `machine` facet)." [source](https://runmachine.dev/) |
| MCP-server hosting | Not supported | "Does not host MCP servers as a managed workload (you could run one manually inside a VM, but it is not a `machine` primitive)." [source](https://runmachine.dev/) |
| MCP server | Not supported | "`machine` exposes no Model Context Protocol control server (no /.well-known/mcp, no documented MCP endpoint or npm-installable MCP server). The chrome-devtools-mcp plugin ships INSIDE the pre-installed Claude Code, which is the agent's, not a `machine` facet." [source](https://runmachine.dev/) |
| Model inference API (first-party) | Not supported | "Serves no first-party model inference API." [source](https://runmachine.dev/) |
| Preinstalled coding agent | Not assessed |  |

### Networking & delivery

| Capability | Status | Evidence |
| --- | --- | --- |
| Automatic HTTPS | Not supported | "Lima auto-forwards guest ports to 127.0.0.1 on the host (plain HTTP localhost); no per-workload TLS/HTTPS." [source](https://runmachine.dev/docs/) |
| Custom domains | Not supported | "No custom-domain mapping; guest services are reachable only at 127.0.0.1 on the host." [source](https://runmachine.dev/docs/) |
| Direct public IPv6 | Not supported | "Guest VMs sit behind Lima NAT with host-local (127.0.0.1) port forwarding; no per-instance stable public IPv6 for raw TCP/UDP." [source](https://runmachine.dev/docs/) |
| Edge KV store | Not applicable | "Not an edge-runtime KV store." [source](https://runmachine.dev/) |
| Egress controls | Not supported | "Guest gets NAT egress via Lima; no configurable egress firewall / allowlist / outbound policy is exposed (the security model restricts host access — no fs mount, tmpfs secrets, agent-forward-not-copy — not guest egress)." [source](https://runmachine.dev/docs/) |
| Email send / receive | Not supported | "No email send/receive capability." [source](https://runmachine.dev/) |
| Public preview URLs | Not supported | "Ports forward to 127.0.0.1 (localhost) only — no public/shareable preview URL for a running service." [source](https://runmachine.dev/docs/) |
| Private networking | Not supported | "Per-project VMs are isolated from each other ('one project can't see another') — the opposite of a private inter-service mesh/VPC. No private service-to-service networking between VMs is advertised." [source](https://runmachine.dev/) |
| Built-in reverse proxy | Partially supported | "'Lima auto-forwards any listening guest port to 127.0.0.1 on the host' — host-local port forwarding to guest services, not a routing/ingress reverse proxy for external traffic." [source](https://runmachine.dev/docs/) |

### Organisation & security

| Capability | Status | Evidence |
| --- | --- | --- |
| Built-in auth | Not supported | "No authentication/IAM layer — a local single-user CLI." [source](https://runmachine.dev/) |
| BYOC | Not applicable | "Self-host OSS runs entirely on your own Mac by definition (covered by self-host-oss); BYOC as a managed-service 'deploy into your cloud account' concept does not apply." [source](https://runmachine.dev/) |
| Deploy into customers' VPCs | Not assessed |  |
| Secrets management | Supported | "First-class tmpfs secrets: `machine secrets` renders 1Password Environment(s) into VM tmpfs ($XDG_RUNTIME_DIR/dev-secrets, wiped at shutdown); git signing-key resolution supports OP_SIGNING_KEY_REF via `op read`." [source](https://runmachine.dev/docs/) |
| Self-host / OSS core | Supported | "MIT-licensed; self-host is the ONLY deployment — `brew install katspaugh/machine/machine` (or a git-clone dev mode / Nix flake) on your own Mac." [source](https://github.com/katspaugh/machine) |
| Sharing | Not supported | "No share-a-running-VM-by-link primitive; access is host-local SSH / port forwarding." [source](https://runmachine.dev/) |
| SSO / SAML | Not supported | "No SSO/SAML (no auth layer at all)." [source](https://runmachine.dev/) |
| Teams | Not supported | "A local single-user CLI — no team accounts / membership / organizations." [source](https://runmachine.dev/) |
| Workload identity | Not assessed |  |

### Developer access

| Capability | Status | Evidence |
| --- | --- | --- |
| CLI | Supported | "The official `machine` CLI IS the product (up/create/down/ssh/claude/run/list/destroy/bake/secrets/init/doctor), with bash/zsh/fish completions." [source](https://runmachine.dev/docs/) |
| E2B-compatible API | Not assessed |  |
| Filesystem API | Not supported | "No remote filesystem API over HTTP; file access is via SSH / IDE Remote-SSH into the guest." [source](https://runmachine.dev/docs/) |
| Git deploy | Not supported | "No push-to-deploy. Repos are `git clone`d into the VM and commits are signed/pushed to GitHub via the forwarded SSH agent, but there is no deploy-an-app-on-push platform." [source](https://runmachine.dev/docs/) |
| HTTP data API | Not applicable | "Data-plane HTTP query API primitive — not applicable." [source](https://runmachine.dev/) |
| OpenAPI spec | Not supported | "No API, hence no OpenAPI/Swagger spec." [source](https://runmachine.dev/) |
| Private container registry | Not supported | "No hosted private container/image registry (VMs are Lima disk images, not registry-pulled OCI images)." [source](https://runmachine.dev/) |
| Public API | Not supported | "No programmatic HTTP API — `machine` is a local CLI only." [source](https://runmachine.dev/docs/) |
| SDK | Not supported | "No client SDK library — CLI + Lima templates only." [source](https://runmachine.dev/) |
| SSH access | Supported | "`machine ssh [p]` opens an interactive shell (cwd = ~/code/<primary-repo>); Lima writes a per-VM SSH config so `ssh lima-<project>` and IDE Remote-SSH (VS Code / Cursor / JetBrains Gateway) work; `machine run <p> <cmd>` runs commands (full-screen TUIs supported)." [source](https://runmachine.dev/docs/) |

### Compute & storage

| Capability | Status | Evidence |
| --- | --- | --- |
| Cloud-init / ignition config | Partially supported | "Per-project VMs are customised at boot by Lima's cloud-init: `mode: data` dotfiles + `provision/*.sh` scripts run on every boot, and git identity/signing key arrive as Lima `--set` params rendered into ~/.gitconfig. A user-facing, version-controlled declarative launch-time init — though authored as Lima templates + shell provision scripts, not a raw cloud-init user-data field." [source](https://runmachine.dev/docs/) |
| Desktop / computer-use sandbox | Not applicable | "Headless Linux VMs — no virtual desktop / computer-use GUI sandbox. (The cypress/playwright profiles run Xvfb for headless browser TESTING, not a computer-use desktop.)" [source](https://runmachine.dev/) |
| GPU compute | Not supported | "No GPU provisioning/passthrough advertised; Lima vz VMs on a Mac — any GPU is the operator's own hardware, not a `machine` facet." [source](https://runmachine.dev/) |
| Live-state (memory) snapshots | Not assessed |  |
| Multi-region | Not applicable | "Runs on your single local Mac — there is no geographic placement / region concept for a local desktop tool. Category-wrong, not a gap." [source](https://runmachine.dev/) |
| Object storage | Not supported | "No managed S3-compatible / blob object store provided to workloads." [source](https://runmachine.dev/) |
| Persistent disk | Supported | "Each project VM has its own durable qcow2 disk (default 30 GiB, configurable); `machine down` 'Stop the VM (preserves disk)', deleted only on `machine destroy`. Durable per-project storage, not ephemeral." [source](https://runmachine.dev/docs/) |
| Sandbox templates / custom images | Supported | "VMs are built from version-controlled Lima templates + provision scripts composed via Lima's `base:` mechanism (base VM + opt-in profile templates: cypress, playwright, supabase-fly), and a baked cached base disk is reused — reusable image/template stacks you fork per-project VMs from. 'To add a profile: copy an existing templates/<name>.yaml, point it at a new provision/<name>.sh.'" [source](https://runmachine.dev/docs/) |
| Scale to zero | Not supported | "VMs run until `machine down`; no automatic idle-suspend / scale-to-zero (and no usage billing to scale)." [source](https://runmachine.dev/docs/) |
| Selectable isolation runtime | Not assessed |  |
| Snapshots / forking | Partially supported | "`machine bake` builds a cached base disk in ~/.cache/machine prepended as the top-priority image for every project VM (a golden-base fork pattern), but there is no user-facing snapshot / restore / clone of a RUNNING VM." [source](https://runmachine.dev/docs/) |

### Data

| Capability | Status | Evidence |
| --- | --- | --- |
| Database branching | Not applicable | "Data-layer (copy-on-write DB branch) primitive — not applicable to a dev-environment VM tool." [source](https://runmachine.dev/) |
| Ephemeral instant DB (no-signup) | Not applicable | "No-signup claimable-DB primitive — not applicable." [source](https://runmachine.dev/) |
| First-party database | Not supported | "No platform-provided managed database. (The supabase-fly profile installs the Supabase CLI + flyctl as dev TOOLING inside the VM; that is not a `machine`-provided DB service.)" [source](https://runmachine.dev/) |
| Vector search | Not applicable | "No vector store/search — not a data layer." [source](https://runmachine.dev/) |

### Platform & operations

| Capability | Status | Evidence |
| --- | --- | --- |
| Managed CI/CD runners | Not supported | "Not a managed GitHub Actions/GitLab CI runner platform." [source](https://runmachine.dev/) |
| Built-in observability | Not supported | "No first-party metrics/logs/tracing/APM. `machine list` / `machine doctor` are ops/preflight helpers, not workload observability (on provision failure it points you at `limactl shell <vm> sudo tail /var/log/cloud-init-output.log`)." [source](https://runmachine.dev/docs/) |
| Preview environments | Not supported | "Per-PROJECT durable VMs, not per-PR ephemeral environments; no git-PR trigger / auto-teardown-on-merge / bundled DB branch." [source](https://runmachine.dev/docs/) |
| Scheduled tasks | Not supported | "No cron/scheduled-job primitive; VMs are created/used interactively." [source](https://runmachine.dev/) |
| Project template marketplace | Not supported | "Bundled profiles (cypress, playwright, supabase-fly) you copy/extend — no marketplace/gallery of starter templates to clone." [source](https://runmachine.dev/docs/) |
| Durable workflows | Not supported | "No durable-execution / workflow engine." [source](https://runmachine.dev/) |

## Agent readiness

### Read: 5 of 10 signals present

5/10 signals (4 full, 1 partial) — a static GitHub Pages site with strong meta but no machine-discovery files

- Llms txt: fail — "GET /llms.txt returns the GitHub Pages 404 page (no llms.txt). Static GitHub Pages site."
- Llms full txt: fail — "GET /llms-full.txt absent (GitHub Pages 404)."
- Robots AI policy: partial — "GET /robots.txt 404s (no robots.txt) → default-allow (nothing disallowed) = half, per rubric v3 (absent robots ≠ fail; only an active Disallow of AI UAs is fail)."
- JSON LD: fail — "No <script type=application/ld+json> block on the homepage (grep of homepage.html: 0 hits)."
- Sitemap: fail — "GET /sitemap.xml 404s (GitHub Pages 404) and there is no robots.txt Sitemap: pointer. Absent."
- Meta quality: pass — "<title>machine — one ready-to-work Linux machine per project</title> + meta description + complete OG (title/type/url/description/image/image:alt) + twitter summary_large_image card. Complete + descriptive."
- Markdown negotiation: fail — "Static GitHub Pages HTML — no per-page markdown variant served (the README markdown lives on GitHub, a separate surface)."
- Content efficiency: pass — "Homepage 34.2 KB HTML → ~9.8 KB readable text ≈ 28.7% (>5%); server-rendered static site with token/component CSS (no JS shell)."
- Docs discoverable: pass — "'The machinist's manual' (/docs/) is a first-class nav link; reachable without JS (static HTML)."
- Pricing machine readable: na — "No pricing surface — `machine` is free MIT OSS (self-host). Dropped from the denominator."
- Anti bot: pass — "No challenge on public content — homepage/docs/sandboxing-guide all fetched 200 headlessly (curl) 2026-07-23. Static GitHub Pages, no bot manager."

### Drive: 1 of 9 signals present

1/9 signals (1 full) — a local macOS CLI with no hosted / API / MCP integration surface

- Public API: fail — "No programmatic HTTP API — `machine` is a local CLI only."
- Openapi spec: fail — "No API, hence no OpenAPI/Swagger spec."
- MCP server: fail — "No Model Context Protocol server (no /.well-known/mcp, no documented MCP endpoint or npm-installable MCP server). The chrome-devtools-mcp plugin is inside the pre-installed Claude Code agent, not a `machine` MCP surface — verified not a coincidental substring."
- SDK packages: fail — "No client SDK library — CLI + Lima templates only."
- Auth docs: fail — "No API and no API-auth documentation (the tool authenticates to GitHub via your forwarded host SSH agent, not an API key it issues)."
- Agent self serve creds: na — "Self-hosted OSS — no hosted signup / credential-issuance surface; you `brew install` it and supply your own agent credentials. Dropped from the denominator (needs a hosted endpoint)."
- Webhooks: fail — "No webhooks."
- CLI tool: pass — "Official `machine` CLI — the entire product (up/create/down/ssh/claude/run/list/destroy/bake/secrets/init/doctor) with shell completions."
- Error model: fail — "No API error model. CLI failures point you at cloud-init logs (`limactl shell <vm> sudo tail /var/log/cloud-init-output.log`), not a documented JSON error schema."
- Rate limit docs: na — "No hosted API to rate-limit — a local CLI. Dropped from the denominator (needs a hosted endpoint)."
- Agent config: fail — "No agents.md / /.well-known/agent / skills-listing surface on the site (the pre-wired Claude Code plugin set is agent CONFIG baked into the VM, not a machine-discovery surface)."

## Coding harnesses

- Claude Code (Anthropic) — "'Claude Code comes pre-installed with the official marketplace and these plugins enabled: frontend-design, superpowers, github, typescript-lsp, security-guidance, commit-commands, chrome-devtools-mcp, supabase. Permission defaultMode is set to auto.' Plus `machine claude [p]`: 'Launch claude in a tmux session in the VM.'" [source](https://runmachine.dev/)
- Codex CLI (OpenAI) — "'Claude Code and Codex ship in the base image, wired to the official Claude marketplace and a curated plugin set.' 'agent CLIs (Claude Code, Codex)' are provisioned in the base VM." [source](https://runmachine.dev/)

Plausible compatibility (derived, not stored):

- Aider
- Amp
- Antigravity
- Devin
- Droid
- Gemini CLI
- Goose
- Hermes Agent
- Kilo Code
- Kiro CLI
- OpenCode
- Pi
- Qwen Code

## Open source

- Repository: https://github.com/katspaugh/machine
- License: MIT
- Stars: 15
- Forks: 0
- Self-host methods: package-manager, source-build

## Company & presence

- Headquarters: Not disclosed
- Founded: Project 2026 (repo created 2026-05-13); maintainer `katspaugh` on GitHub since 2010-08-31
- Team size: Solo / individual (maintainer `katspaugh`)
- Terms of service: https://github.com/katspaugh/machine/blob/main/LICENSE
- GitHub: https://github.com/katspaugh/machine
- Website: https://runmachine.dev/
- Docs: https://runmachine.dev/docs/

## Nearby in the atlas

- [Catnip](/products/catnip.md)
- [Docker Offload](/products/docker-offload.md)
- [exe.dev](/products/exe.dev.md)
- [machine0](/products/machine0.md)
- [Multipass](/products/multipass.md)
- [ShellBox](/products/shellbox.md)

## Method

Facts come from the product's own public pages. Each claim carries its evidence: a quote and the page it came from. We count capabilities rather than grade products, and "Not assessed" means we have not checked, never that the product lacks it.