Runspace vs Runme

Runme is a free, open-source (Apache 2.0) notebook tool for engineers who want runnable Markdown docs in VS Code, a CLI or a self-hosted web app. Runspace, by Gravityloop, is commercial software for platform and SRE teams that need runbooks governed centrally: per-run approval by a separate reviewer, reviewed and unchangeable revisions, and a server-side audit log. Runspace is in private pilots.

Both tools start from the same idea: the runbook should be something you run, not something you copy from. Each step executes inline and its output appears underneath, like a notebook. They differ in who controls a run once a team, not one engineer, is doing the work.

Runspace vs Runme at a glance

	Runspace	Runme
Execution model	Steps run inline in a shared team workspace. Output streams under each step. Variables can capture values from an earlier step’s output.	Cells run inline in a notebook on whatever machine hosts the kernel: a laptop, VM, cloud dev environment or SSH host. No central server or runner fleet found.
Approvals	Each run is approved by a separate reviewer, pinned to the exact command and runbook revision.	None found in the open-source docs or site.
Audit	Server-side log of who ran what, where, and who approved it.	No central audit log found.
Access control	Roles and restricted runbooks control who can edit, run and approve.	None found.
SSO	Sign in through your identity provider.	None found.
Change review / versioning	Changes are reviewed and approved in the product before publishing. Approvers see only what changed. Published revisions can’t change.	Notebooks are plain Markdown in Git, reviewed through ordinary pull requests.
AI / agent help	Claude Code or Codex suggests the next command. Nothing runs without approval.	Foyle integration generates notebook cells. Experimental runme eval runs task datasets against local agents (codex, claude-code, cursor-cli).
Deployment	Not yet published. Available through private pilots.	VS Code extension (also Cursor and VSCodium/Open VSX), CLI, self-hosted web app, Docker, cloud dev environments, GitHub Action.
License	Commercial.	Apache 2.0. CNCF Sandbox project.
Pricing	Solo $20/month. Multiplayer $40/user/month ($34 billed annually), 2-seat minimum. Not final.	Free. No paid tier found.

“None found” means the feature isn’t in Runme’s public docs. It doesn’t prove the feature can’t be built around Runme. An older Stateful extension was described as adding “authentication, collaboration, and security” on top of Runme, but we couldn’t confirm it still exists. stateful.com now markets an unrelated product.

Where Runme is stronger

Open source and free. Runme is Apache 2.0 with no paid tier we could find. You can read the code, fork it, and run it without a procurement cycle. Runspace is commercial and its pricing isn’t final.

Maturity and adoption. Runme was accepted as a CNCF Sandbox project on 2025-01-21. Its latest release is v3.17.6 (2026-10-05), and its site claims about 147k installs and 2.4k GitHub stars. Runspace is in private pilots and has no public install base to point to.

It meets engineers where they already work. Runme runs inside VS Code, Cursor and VSCodium, and as a CLI. Engineers don’t open a separate app to run a doc. Runspace is its own workspace.

Self-hosting. Runme ships a self-hosted web app and a Docker image, and runs in cloud dev environments. Runspace hasn’t published its deployment options yet.

Notebooks as CI tests. A GitHub Action lets you test Runme notebooks in CI, so a broken runbook can fail a build. Runspace doesn’t document anything equivalent.

Git-native review. Because notebooks are plain Markdown, they go through the same pull-request process as your code. For many teams that’s a credible review model, and it costs nothing extra.

Scheduling. Neither tool documents scheduled runs. If you need jobs on a schedule with blackout calendars and retries, that’s a job-runner’s territory (Rundeck and PagerDuty Runbook Automation list these features), not a notebook’s.

Where Runspace differs

Runspace’s difference is governance that lives in the product, not in conventions around it.

Approval by someone else, pinned to what runs. In Runspace, a risky step is approved by a separate reviewer, and the approval is tied to the exact command and runbook revision. If the command or runbook changes, the approval doesn’t carry over. We found no approval step in Runme’s docs. Whoever has the notebook open and a kernel attached can run the cell.

Review before publish, enforced in the product. Runspace runbook changes are reviewed and approved before they publish, and approvers see only what changed. Once published, a revision can’t change. With Runme, review depends on your Git branch protection and PR habits, which works well when everyone follows them and is easy to bypass on a laptop.

A central record of what ran. Runspace keeps a server-side audit log of who ran what, where, and who approved it. Runme runs on the machine hosting the kernel, and we found no central audit log. After an incident, the record of what was executed is whatever that machine kept.

Roles and SSO. Runspace has roles, restricted runbooks and single sign-on. Runme’s open-source docs don’t describe any of these.

Incidents become runbooks. Runspace can turn shell history or an incident’s terminal session into a runbook draft, which then goes through the same review. Findings and evidence are captured as you investigate. Runme doesn’t document anything comparable.

Agent help with a hard stop. In Runspace, Claude Code or Codex suggests the next command, and nothing runs without approval. Runme’s Foyle integration generates cells, and its docs say it “can automatically create and execute” them, though the examples show the user running them.

Where Runspace is weaker today: it’s pre-launch. There are no published customers, no certifications (no SOC 2), and agent help with Claude Code and Codex is the only integration listed. Runspace also doesn’t run in your editor or test runbooks in CI.

Which should you choose?

Choose Runme if your engineers want runnable docs in their editor, your runbooks already live in Git, PR review is enough control for you, and you want something free and open source today. It’s also the better fit if you want to self-host, or test runbooks in CI.

Choose Runspace if production runbooks are run by more than one person and you need to show who approved each risky command, against which revision, with a server-side record afterward. It’s built for teams where runbooks are wiki pages run by copy-paste and there’s no record of what ran.

Use both if engineers draft and test procedures as Runme notebooks, and the subset that touches production needs separate-reviewer approval and a central audit trail.

Look elsewhere if you mainly need scheduled jobs, retries and a large plugin library. Neither tool is a job scheduler.

Runspace is in private pilots with a small number of teams. If the governance gap above matches your team’s, request a pilot with your work email and we’ll reach out to set one up with your team.