Runspace vs Rundeck (PagerDuty Process Automation)

Rundeck is a job-automation platform. It suits teams that run existing scripts and workflows across many nodes, triggered on a schedule, through an API or from a UI. Its core is open source under Apache 2.0, and PagerDuty sells commercial editions. Runspace is a runbook workspace, currently in private pilots. Its steps run inline like a notebook, and a separate reviewer approves each run, pinned to the exact command and runbook revision.

A note on names

PagerDuty has renamed the commercial line twice. Rundeck Enterprise became PagerDuty Process Automation (On-Prem) in 2022 and is now called Runbook Automation Self-Hosted. The SaaS edition, formerly Rundeck Cloud, is Runbook Automation. “Process Automation” now survives only as the name of the pricing page. The open-source project is still called Rundeck. This page uses “Rundeck” for the product family and names an edition where the difference matters.

Comparison table

	Rundeck / Runbook Automation	Runspace
Execution model	Jobs and workflows built from existing scripts and tools. They run against nodes over SSH or WinRM by default, through a pluggable executor. The SaaS edition uses Runbook Runners, agents inside your network.	Executable runbooks. Each step runs inline and its output streams underneath, like a notebook. Variables can capture values from an earlier step’s output.
Approvals	No native per-run approval gate found in the docs. PagerDuty’s marketing describes “approval workflows” that control which automations are available. A per-run reviewer gate is unverified.	Each run is approved by a separate reviewer. The approval is tied to the exact command and runbook revision.
Audit	Audit trail of logins, views, job create, run, update and delete, and ACL changes. A commercial Audit Stream Plugin sends events to Datadog, New Relic, Splunk or webhooks.	Server-side audit log of who ran what, where, and who approved it.
Access control	YAML ACL policies on projects, jobs, nodes and other resources, assigned to groups. The GUI ACL builder is commercial.	Roles and restricted runbooks control who can edit, run and approve.
SSO	Open source: LDAP/AD via JAAS, PAM, pre-authenticated headers, container auth. OIDC/OAuth2 SSO is commercial.	Sign in through your identity provider. Supported providers aren’t documented yet.
Change review / versioning	The Git SCM plugin exports job definitions to a Git repo, so review happens in pull requests outside the product. No built-in review step before publishing was found.	Changes are reviewed and approved in the product before they publish, and approvals show only what changed. Published revisions can’t be changed.
AI / agent help	The Rundeck MCP Server went GA on 2026-10-07 for 6.1.0+ and works with Claude, Cursor, VS Code and Codex. It builds and runs jobs with the user’s own API token and asks for human confirmation on destructive actions. The SaaS edition can also generate a starting job from a prompt.	Claude Code or Codex suggests the next command as you work. Nothing runs without approval.
Deployment	Open source self-hosted, commercial self-hosted (needs a license file), or SaaS with a 99.9% SLA.	Not documented yet.
License	Open source: Apache 2.0. Commercial editions: licensed.	Paid product. License terms aren’t documented.
Pricing	Open source is free. SaaS is $125 per user per month plus a platform fee, with a 14-day trial. Self-Hosted is “Call Us”.	Solo $20/month. Multiplayer $40/user/month ($34 billed annually), 2-seat minimum. Pricing isn’t final.

Where Rundeck is stronger

Rundeck is the more mature product, and for many teams it’s the right one.

• Maturity and scale. Rundeck has run production automation for over a decade. The commercial editions add HA clustering, enterprise support and a 99.9% SLA on SaaS. Runspace is in private pilots and has none of that track record.
• Scheduling and job operations. Rundeck lists scheduling, blackout calendars, job queuing, resuming failed jobs and retrying failed nodes. If your runbooks are really recurring jobs, Rundeck is built for that. Runspace’s documented model is a person working through a runbook.
• Integrations. The listed integrations include ServiceNow, Kubernetes, Ansible, Datadog, VMware and GitHub, plus advanced webhooks and a large plugin ecosystem. Runspace’s only documented integrations are agent help through Claude Code and Codex.
• Private networks. Runbook Runners let the SaaS edition reach hosts inside your network without inbound access.
• Self-hosting and open source. You can run the Apache 2.0 core yourself for free, or license the commercial self-hosted edition. Runspace hasn’t documented a self-hosted option.
• Agents with real write access. As of October 2026, Rundeck’s MCP server can create, import and run jobs and write ACL policies from Claude, Cursor, VS Code or Codex.
• Distribution. Runbook Automation is sold as part of PagerDuty’s Operations Cloud and ties into incident management. If you already use PagerDuty, that’s a short path.

Where Runspace differs

Runspace isn’t a job scheduler. It’s designed for runbooks that people work through step by step, with governance built into the product.

• Notebook-style execution. Instructions, checklists and commands live in one document. Each step runs inline and its output appears right beneath it, so the doc and the execution never drift apart.
• Per-run approval by a separate reviewer. Rundeck’s ACLs decide who may run a job. Runspace adds approval of this specific run by another person, pinned to the exact command and runbook revision. We found no documented equivalent in Rundeck.
• Review before publish, inside the product. In Rundeck, review happens in Git pull requests through the SCM plugin. That’s a credible approach for many teams. Runspace enforces review in the product, shows reviewers only what changed, and locks published revisions so they can’t be edited.
• A more conservative agent default. Rundeck’s MCP server runs jobs with the user’s token and asks for confirmation only on destructive actions. In Runspace, the agent suggests commands and none of them runs without approval.
• Incidents become runbooks. Runspace can turn shell history or an incident’s terminal session into a runbook draft. The draft then goes through the same review before it publishes.
• Audit at step level. Rundeck has a strong audit log for jobs. Runspace’s server-side log covers inline runbook steps: who ran what, where, and who approved it.

Which should you choose?

• You need scheduled, recurring or API-triggered automation across fleets: choose Rundeck. Runspace doesn’t target this.
• You need self-hosting, open source or a published SLA today: choose Rundeck. The open-source edition is free, and the commercial editions are established.
• You depend on ServiceNow, Ansible or Kubernetes plugins, or you’re already a PagerDuty customer: Rundeck fits better.
• Your runbooks are wiki pages people copy-paste from during incidents, and you need a record of what ran and who approved it: Runspace is built for that gap.
• Your security or change process requires a second person to approve each production run of a specific command: Runspace documents this, and we found no Rundeck equivalent.
• You want both: keep scheduled automation in Rundeck and move the human-run procedures to Runspace.

Runspace is in private pilots with a small number of teams. It holds no certifications yet. If you want to evaluate it, request a pilot with your work email and we’ll reach out to set one up with your team.