Runspace vs Gruntwork Runbooks

Gruntwork Runbooks is a free, open-source (MPL 2.0) desktop app. Platform teams use it to package their patterns as MDX runbooks, and developers run them locally with their own credentials. Runspace is a commercial, team workspace for production runbooks. Its core difference is governance: each run is approved by a separate reviewer and pinned to the exact command and runbook revision, published revisions cannot change, and a server-side audit log records every run. Runspace is currently in private pilots.

What each tool is

Gruntwork Runbooks describes itself as “Expert knowledge that anyone can run”. It is aimed at developers who need to apply a platform team’s patterns. Runbooks are written in MDX and opened in an Electron desktop app for macOS, Linux and Windows. The app renders forms, runs checks and commands, and streams their output. Its building blocks include <Command>, <Check>, <Template>, <AwsAuth>, <GitHubAuth> and <GitHubPullRequest>. Gruntwork states there is “no server to deploy.”

Runspace (by Gravityloop) is built for teams that run production. Instructions, checklists and commands live together in one workspace. Each step runs inline and its output streams underneath, the way a notebook works. Teams share runbooks and control access with roles and restricted runbooks. An agent (Claude Code or Codex) can suggest the next command, but nothing runs without approval. During an incident, the terminal session can be captured and turned into a runbook draft for the team to review.

Comparison

	Gruntwork Runbooks	Runspace
Execution model	Runs locally on the developer’s machine with the developer’s own credentials. Output streams in the app. No server.	Steps run inline in a shared workspace with output streamed under each step. Variables can capture values from an earlier step’s output.
Approvals	The user confirms a trust banner and clicks Run. Changed scripts need a hash-checked “Reload script”. All of this is self-confirmation, not a separate reviewer.	Each run is approved by a separate reviewer, and the approval is pinned to the exact command and runbook revision.
Audit	None found. The execution-model page describes no audit log.	Server-side audit log of who ran what, where, and who approved it.
Access control	None found.	Roles and restricted runbooks control who can edit, run and approve.
SSO	None found.	Sign in through your identity provider.
Change review / versioning	Runbooks live in Git and are reviewed in PRs. They can be opened from a GitHub or GitLab URL.	In-product review before publishing. Approvers see only what changed, and published revisions cannot change.
AI / agent help	An “Author with AI” page supplies docs as LLM context for writing runbooks. No in-app agent found.	An in-workspace agent (Claude Code or Codex) suggests commands. Nothing runs without approval.
Deployment	Desktop app. No server to deploy.	Not documented publicly. Discussed during the pilot.
License	MPL 2.0	Commercial
Pricing	Free	Solo $20/month. Multiplayer $40/user/month ($34 annual), 2-seat minimum. Pricing isn’t final.

Where Gruntwork Runbooks is stronger

• Cost and license. It is free and open source under MPL 2.0, so you can read, fork and modify it. Runspace is a paid commercial product.
• Nothing to host. It has no server to deploy, operate or put through a security review as a new service. Commands run on the developer’s machine with credentials they already have. For a platform team that wants to ship guided workflows without adding infrastructure, this matters.
• Git-native workflow. Runbooks are MDX files in Git, reviewed in the same PRs as everything else. The app can open a runbook directly from a GitHub or GitLab URL. Many teams already trust Git review, and it is a credible alternative to in-product review.
• Golden-path tooling. Building blocks for templates, AWS and GitHub authentication, and opening GitHub pull requests make it a good fit for generating files and getting developers onto a platform team’s standard patterns. Runspace does not target that problem.
• Availability and backing. It is publicly released and comes from a company known for infrastructure work. It is still pre-1.0 (v0.26.0, released 2026-10-06), and the repository has about 31 stars. Runspace is not generally available; it is in private pilots.
• Scheduling. Neither tool documents scheduled runs. If you need jobs on a timer, neither is the right tool today.

Where Runspace differs

The gap is governance and shared operation, not the ability to run a command from a document. Both tools can do that.

• A second person approves the run. Gruntwork’s trust banner and Run click are confirmed by the person running the runbook. In Runspace, a separate reviewer approves each run. That approval is tied to the exact command and runbook revision, so it cannot be reused for a different command.
• Review happens in the product. Runspace reviews changes before they publish and shows approvers only what differs. Published revisions cannot be edited afterwards. Gruntwork leaves review to Git and PRs outside the app.
• There is a central record. Gruntwork runs locally, and we found no audit log. Runspace keeps a server-side log of who ran what, where, and who approved it. That is the record you need after an incident, or when someone asks what was changed in production.
• Access is controlled. Runspace has roles, restricted runbooks and SSO. We found none of these documented for Gruntwork Runbooks, which is consistent with a local tool that relies on each user’s own credentials.
• Incidents become runbooks. In Runspace you capture findings and commands while you investigate, request approval mid-incident, and turn terminal history into a runbook draft for review. Gruntwork’s documented AI help is focused on writing runbooks, not on running incidents.

Runspace has no customers, integrations or certifications to point to yet. It does not have SOC 2. Agent help works with Claude Code and Codex. Beyond that, integrations are shaped by what pilot teams need.

Which should you choose?

Choose Gruntwork Runbooks if your problem is developer self-service. That means your platform team wants developers to apply its patterns (generate files, authenticate to AWS or GitHub, open a PR) without filing a ticket. It also fits if you want a free, open-source tool with no server, and if Git review plus each developer’s own credentials is enough control.

Choose Runspace if your problem is production operations. That means runbooks living in wiki pages, commands run by copy-paste, and no record of what actually ran. It fits if risky steps should be approved by someone other than the operator, if approvals need to be tied to an exact command and revision, and if you need roles, SSO and a server-side audit log.

Use both if you want to split the jobs. Gruntwork Runbooks can cover golden paths for application developers, while Runspace covers incident and production runbooks run by SRE and platform teams. The two target different users, so they don’t compete for the same work.

If neither fits because you need scheduled jobs, retries, or a mature hosted service with an SLA today, neither tool documents those capabilities.

Runspace is in private pilots with a small number of teams. If the governance model fits how your team runs production, request a pilot with your work email, and we’ll reach out to set one up with your team.