When Rundeck open source is enough and when Runbook Automation is worth it
A team already running operations jobs on Rundeck has to decide whether the free edition still fits. Rundeck Open Source is licensed under the Apache Software License 2.0, and the Rundeck documentation describes it as free for teams that write and run Rundeck jobs at small scale. Runbook Automation, formerly Rundeck Enterprise and Process Automation, is PagerDuty's commercial offering built on open source Rundeck. It is offered as Runbook Automation Self-Hosted and as SaaS. The open source edition stays the right choice while a small group of operators writes jobs, runs them from the web console or CLI, and manages access through the controls the open source project provides. Check that your job volume, number of operators and node count still sit within what the documentation describes as small scale, and keep the embedded H2 database out of production, since the Rundeck documentation says it is not safe for production because it is not resilient if Rundeck is not shut down gracefully.
Runbook Automation becomes worth evaluating when the operations service itself becomes an enterprise dependency. Typical triggers include a larger operator population that needs governed access, a need for vendor-backed support on the platform, or a requirement to run the service as a managed SaaS rather than on your own hosts. Each of these needs to be tied to a written requirement before you talk to PagerDuty. Ask PagerDuty to confirm, in writing, which paid features are included in each form, self-hosted and SaaS, and how they map to your access control, audit, scheduling and integration requirements. Do not assume a feature is included because it sounds like an enterprise feature. The paid feature list must be confirmed with PagerDuty against your team's requirements, and the comparison of editions should be read alongside that written answer.
The cost question is the one-time and recurring split. The open source edition carries no license fee, but your team pays for the database, hosting, upgrades, backups and the staff time to run them, and the Rundeck system requirements list supported databases such as PostgreSQL 15.5 or later and Java 17. A commercial edition adds a subscription, and the quote should state which component is covered, the support terms and the upgrade path. Ask for the subscription scope, the self-hosted or SaaS responsibilities split, and what happens to your jobs and configuration if you later move between forms.
Which Rundeck capabilities are in the free edition and which the paid edition adds
This table maps each core Rundeck capability to what the Apache-2.0 open-source edition documents and what to confirm for PagerDuty's Runbook Automation, Self-Hosted and SaaS. Where the supplied documentation does not state which edition holds a feature, the paid column says to confirm it, so do not assume a split until PagerDuty confirms it in writing. The main takeaway is that the feature list alone does not settle the paid boundary.
| Capability | Rundeck Open Source (Apache-2.0) | Runbook Automation (paid, self-hosted or SaaS) |
|---|---|---|
| Access control | Listed as a core feature in the Rundeck documentation | Confirm which access control features and policy tooling are included in each commercial form |
| Scheduling | Listed as a core feature in the Rundeck documentation | Confirm whether scheduling limits or features differ from the open-source edition |
| Error handling and logging | Listed as core features in the Rundeck documentation | Confirm whether log retention, export or monitoring options are added in the commercial forms |
| Option passing and web GUI | Listed as core features in the Rundeck documentation | Confirm whether any console or option features differ from the open-source web GUI |
| REST API and CLI tools | Listed as a core feature with CLI tools and a web API | Confirm API scope and CLI versions supported for each commercial form |
| External authentication, resource model and option data | Integration with external sources for authentication, resource model and option data is documented | Confirm which external integrations are supported in Self-Hosted versus SaaS |
| Supported databases | MariaDB 10.11.6 or later, MySQL 8.0.35, 8.4 or later, PostgreSQL 15.5 or later, SQL Server 2022, Oracle 19c or later (system requirements) | Confirm whether the same database list applies to Self-Hosted and SaaS |
| Default embedded H2 database | Default install; documented as not safe for production because it is not resilient if Rundeck is not shut down gracefully | Confirm the database a commercial deployment uses and who manages it |
| Node access over SSH | Linux and Unix nodes reached over SSH with public-key authentication | Confirm node connectivity options for SaaS and any agent requirements |
How licensing, support and updates differ between the two editions
The free Rundeck line and PagerDuty's commercial Runbook Automation share a codebase, but the license holder, the support contract and the update path differ. Each card below names one of the four arrangements and the written commitments a reader should request before depending on it.
Rundeck Open Source under Apache 2.0
Anyone may use the software without a license fee, and the Rundeck documentation describes the free edition as suited to teams that write and run jobs at small scale. No vendor is contractually bound to support it, so support comes from your own staff, the community, or a paid partner you engage separately. Your team applies every update by pulling new releases, which are published on GitHub. The latest supplied release is v6.2.1 from September 9, 2026, with 6.3.0 release candidates following. Check which release line you intend to run, and confirm your own upgrade and backup plan, since nobody else owns that schedule.
Runbook Automation Self-Hosted
PagerDuty licenses this commercial build, which is built on open source Rundeck, and you run it inside your own infrastructure. The license and support terms come from PagerDuty's agreement, not from the Apache 2.0 license, so ask in writing which features, support hours, and escalation paths the contract covers. Your team or a delivery partner still installs, patches and upgrades the servers. Request the upgrade cadence, the notice period for end of support on any version, and whether security fixes reach older releases.
Runbook Automation SaaS
PagerDuty hosts and operates the service, so PagerDuty applies platform updates on its schedule rather than yours. Your responsibilities shift toward configuration, access policy, and the network paths from the hosted control plane to your nodes. Before signing, ask which update windows apply, how maintenance is announced, where your data is stored, and what happens to jobs and credentials at contract end. Confirm the support tiers and response commitments in writing, because they define your recourse during an incident.
Naming history from Rundeck Enterprise
The commercial product was formerly called Rundeck Enterprise and Process Automation, and it now appears as Runbook Automation. Older quotes, invoices, or contract documents may use the former names, so match the product name and edition on each document before comparing terms. Ask PagerDuty to confirm in writing which product names and SKUs your agreement covers, and whether any renewal or migration terms refer to the earlier edition names.
Where the free edition runs out for enterprise operations teams
Enterprise operations teams usually outgrow the free edition when many operators with different duties share one Rundeck instance. The documentation lists access control, logging and integration with external sources for authentication, so separated duties can work in Rundeck open source if you design job and node permissions deliberately. Map each operator group to the jobs and nodes it may run, then test that the logs answer who ran which job, against which node, and when. This holds for a small group that shares one trust boundary and runs its own identity setup. If auditors or internal policy require evidence beyond what your own log pipeline captures, ask PagerDuty which audit, approval or reporting features the commercial Runbook Automation edition adds, since the supplied documentation does not detail that split.
The second break point is the database. The default install uses the embedded H2 database, which the documentation says is not considered safe for production because it is not resilient if Rundeck is not shut down gracefully. Enterprise deployments move to an external database such as MariaDB 10.11.6 or later, MySQL 8.0.35 or 8.4 or later, PostgreSQL 15.5 or later, SQL Server 2022, or Oracle 19c or later, on a Java 17 runtime. The free edition meets this need when your team can provision, back up, restore and patch that database and the Rundeck host. Confirm the database version your standards require with your DBA, and check the system requirements before sizing. Ask PagerDuty whether database hosting or recovery help is included in either Runbook Automation form.
The third need is hands-on support. Shared runbooks used by several teams make an outage in Rundeck itself a cross-team incident, so support hours, response targets and upgrade assistance become selection criteria. The supplied material does not state these terms, so get them in writing for the specific edition and deployment form you buy. New Rundeck releases, such as v6.2.1 published on September 9, 2026, still need testing and rollout by your team. The free edition, licensed under the Apache Software License 2.0 and described as free for teams writing and running Rundeck jobs at small scale, remains a sound choice for teams that can carry patching, backups and incident response themselves. For those teams, the commercial edition should be justified by specific support gaps you can name in a quote request.
How each edition fits different team shapes
A small platform team with a modest job catalog, a few operators and a limited set of nodes usually starts on Rundeck Open Source. The Apache Software License 2.0 edition covers the core job model, scheduling, error handling, logging, option passing, the web GUI, the REST API and the command line tools, and the Rundeck documentation describes it as free for teams that write and run jobs at small scale.
- Core job model: Jobs, schedules, options and logs cover most day-to-day runbook execution without a paid tier.
- Node access: Linux and Unix nodes are reached over SSH with public-key authentication, so key management and the node inventory are the main setup work.
- Database choice: The embedded H2 default is not considered safe for production, so plan an external database from the start.
- Release tracking: Rundeck v6.2.1 was published on September 9, 2026, with 6.3.0 release candidates following, so budget time for regular minor upgrades.
Confirm with PagerDuty that your planned job count, node count and number of operators sit within what the free edition is documented to cover, and confirm the upgrade path if the catalog outgrows it.
A multi-team operations group that shares runbooks across services, on-call rotations and environments usually evaluates Runbook Automation, PagerDuty's commercial offering built on open source Rundeck. It is available as Runbook Automation Self-Hosted or as SaaS, and the reasons to look at it are shared ownership of jobs, central governance and vendor support for a service that many teams depend on.
- Shared ownership: Multiple teams running and maintaining the same runbooks benefit most from role-based access control and clear job ownership, which the open source documentation also describes.
- Central identity: Integration with external sources for authentication, resource model and option data is documented for Rundeck. Confirm which of these integrations sit in the free build and which belong to the paid offering.
- Governance and reporting: Audit reporting and approval workflows are paid capabilities to be verified with PagerDuty before you rely on them.
- Vendor support: Support terms, response commitments and service levels are not part of the supplied facts. Request them in writing.
- Upgrade path: Ask how an existing open source installation moves to the commercial offering, including job definitions, access rules and database migration.
Before committing, ask PagerDuty to map each capability your teams need to either the open source edition or the paid edition, in writing.
A regulated organization that must keep operations tooling inside its own data center or cloud accounts usually looks at Runbook Automation Self-Hosted, or at the open source edition if its scope is small. The main drivers are control over where job logs, options and credentials live, and the ability to keep the platform inside the existing change and backup regime.
- Hosting control: The self-hosted form keeps the control plane in your environment, but confirm which deployment topologies PagerDuty supports for high availability and disaster recovery.
- Database fit: Rundeck documents supported databases including MariaDB 10.11.6 or later, MySQL 8.0.35 or 8.4 or later, PostgreSQL 15.5 or later, SQL Server 2022 and Oracle 19c or later. Check that your chosen database is on your standards list and under your backup policy.
- Runtime: The system requirements list a Java 17 runtime, so include it in your patching and vulnerability management scope.
- Audit evidence: DeployOpen can prepare systems, controls and evidence for a compliance assessment, but it does not issue audit reports or attestations. Independent auditors make that determination.
- Access controls: Confirm how the paid edition extends access control and audit logging to meet your internal control requirements, as these details are to be verified.
Ask for a written statement of supported deployment topologies, database versions and the logging available to your auditors before you select an edition.
A team that prefers to hand hosting, patching and platform operations to the vendor usually considers the SaaS form of Runbook Automation. The trade is less platform administration in exchange for a reliance on PagerDuty's hosting and on how SaaS reaches the nodes you manage.
- Operational offload: Hosting, database administration and runtime upgrades move to the vendor, which removes much of the platform work described for the self-hosted forms.
- Node reachability: Rundeck reaches Linux and Unix nodes over SSH with public-key authentication. Confirm how a SaaS control plane reaches private nodes, including network paths, bastion requirements and where private keys are stored.
- Data location: Confirm where job logs, option values and audit records are stored, which regions they can reside in and how long they are retained.
- Exit path: Ask how jobs, access rules and execution history can be exported if you later move to a self-hosted deployment.
- Paid terms: Service levels, support tiers and data processing terms are not part of the supplied facts and should be requested in writing.
Before committing, have your security team review the SaaS network design and data terms against your own policies, since these are the points that differ most from self-hosting.
What drives the cost of each Rundeck edition
This table sets out the cost components for Rundeck Open Source and PagerDuty's Runbook Automation, showing who is paid for each item and whether it is one-time or recurring. Use it to build a request for quote, because Rundeck pricing is not part of the supplied facts and must come from PagerDuty and any services provider in writing.
| Cost component | Rundeck Open Source | Runbook Automation (Self-Hosted or SaaS) |
|---|---|---|
| Software licence | No licence fee. Apache Software License 2.0 applies, and the documentation describes it as free for teams writing and running jobs at small scale. | Subscription terms set by PagerDuty. Request the edition, term and user count in writing before comparing totals. |
| Hosting and infrastructure | Recurring: servers or VMs in your own environment, plus backup and monitoring. You pay for and operate them. | Self-Hosted: recurring infrastructure you run. SaaS: hosting is included in the subscription, so confirm what the subscription covers. |
| Production database | One-time setup and recurring operation of MariaDB, MySQL, PostgreSQL, SQL Server or Oracle. The default embedded H2 database is not considered safe for production. | Self-Hosted: same database cost as open source. SaaS: confirm whether database operation is included and who handles backups. |
| Staff time for installs and upgrades | Recurring: your team plans, installs and upgrades Rundeck releases and tests them against your nodes and integrations. | Self-Hosted: recurring upgrade effort remains with you. SaaS: reduced platform upkeep, but job and integration maintenance stays with your team. |
| Staff time for job maintenance | Recurring: writing, reviewing and updating jobs, node sources, options and access rules as systems change. | Recurring and similar in both editions. Enterprise features may add administration work, so ask which ones you will configure. |
| Implementation services | One-time or retainer: an implementation partner scopes, installs, hardens and documents Rundeck under a written scope, which DeployOpen delivers on a fixed-scope basis. | One-time or retainer: the same services apply, plus any PagerDuty onboarding or professional services. Ask for the scope and deliverables in writing. |
| What to request in a quote | Confirm the deployment model, node count, database choice, backup and high-availability design, and support needs for your own team. | Ask PagerDuty for edition (Self-Hosted or SaaS), user count, support level, term, renewal terms, price increase limits and what is one-time versus annual. |
Moving from the free Rundeck edition to Runbook Automation, and back
This sequence gives a team a documented path from its current Rundeck instance to a chosen Runbook Automation deployment, or back again, with jobs, access controls and integrations checked at each stage before the old instance is retired.
Inventory jobs, nodes, options and integrations
The Rundeck administrator and the job owners list every project, job, schedule, node source, option and credential reference, plus each external integration for authentication, resource model and option data. The output is a written inventory that marks which items are actively used. Done when every job owner has confirmed their entries and nothing in the list is undocumented.
Confirm the target database
The platform team checks the target database against the documented supported list in Rundeck's system requirements, which includes MariaDB, MySQL, PostgreSQL, SQL Server and Oracle at stated minimum versions. The embedded H2 default is not considered safe for production, so it should not be the target for a production move. Done when the chosen database, version and Java 17 runtime are recorded and checked against the current requirements page.
Check job definitions and integrations for compatibility
Before any move, the team reviews job definitions, option handling, scripts, plugins and external authentication or resource model integrations against the target edition and version. Ask PagerDuty to confirm which features and integrations carry over to the Self-Hosted or SaaS form you are evaluating. Done when each incompatibility is logged with an owner and a fix, or a decision to retire the item.
Plan the move to the chosen deployment
The platform team and DeployOpen, if engaged, agree a written plan covering the target hosting, network path to nodes, SSH public-key access from the new instance, backup of the existing database and a rollback point. The plan names who approves each step. Done when the plan is signed off and the target environment is reachable from the nodes it will manage.
Test jobs and access controls in the new instance
Staging copies of representative jobs run against non-production nodes, and each role's access controls are tested against the expected permissions in the access control model. Scheduled jobs are run manually first to confirm output, logging and error handling match the old instance. Done when test results are recorded, every role has been checked, and any gaps are closed.
Cut over and retire the old instance
The team schedules a cutover window agreed with stakeholders, disables schedules on the old instance, imports the final definitions and enables schedules on the new one. The old instance stays read-only for a retention period set by your own policy before decommissioning. Done when the new instance runs all production schedules, the old scheduler is disabled, and the retention and backup record is complete.
Reverse the path when stepping down
A team leaving Runbook Automation runs the same inventory and compatibility checks in reverse, confirming that features used in the commercial edition have open-source equivalents in Rundeck Open Source. The team then exports definitions, rebuilds the required integrations and repeats the test and cutover steps. Done when a written compatibility list shows which paid-only features are replaced, changed or dropped.
What buyers ask before choosing Rundeck or Runbook Automation
What does running free Rundeck Open Source actually cost?
The software itself carries no license fee, because Rundeck Open Source is Apache Software License 2.0 and the Rundeck documentation describes it as free for teams that write and run jobs at small scale. The recurring cost is the work to operate it: the host or VM, a supported external database, Java 17 runtime maintenance, patching, backups and the time your engineers spend writing and reviewing jobs. Those costs sit in your own budget. Before treating the free edition as the whole answer, estimate how many jobs, users and nodes you expect and whether your team will maintain access control and audit logging without vendor help. Confirm with PagerDuty which capabilities are reserved for the commercial offering.
How long does a move to Runbook Automation take?
No duration is published in the sources available for this page, so ask PagerDuty for its migration path and timeline in writing. The time depends mainly on how many jobs, node definitions, options and integrations you carry over, how much your authentication and resource model rely on external sources, and whether you move to the self-hosted or SaaS form. Teams with a clean job inventory and a documented access model usually spend less time on the cutover than teams whose jobs live only in the web console. Build a job and integration inventory first, because that inventory sets the scope of any quote.
What does the work need from our own team?
Your team needs an owner for the runtime and database, someone who understands your job and node model, and people who can approve changes to access control and schedules. Under self-hosted Runbook Automation, your team also keeps the installation, upgrades and backups running in your environment. Under SaaS, PagerDuty operates the platform, but your team still owns job design, credentials, node reachability and the security decisions about who can run what. Identify these roles before a quote so that the scope reflects who will do the day-to-day work after handover.
Can we run Rundeck ourselves without outside help?
Many small teams run Rundeck Open Source without outside help, provided they have engineers comfortable with Java services, a production database and SSH-based automation. The documentation warns that the default embedded H2 database is not considered safe for production because it is not resilient if Rundeck is not shut down gracefully, so a production install needs an external database from the supported list. Outside help is most useful for designing access control, integrating authentication, hardening, setting up high availability and documenting operations for auditors. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure under fixed-scope engagements, and ongoing support is available as a retainer.
How does SSH public-key access to Linux and Unix nodes affect planning?
Rundeck reaches Linux and Unix nodes over SSH with public-key authentication, so the plan must cover where keys are created, stored and rotated, which service account runs jobs on each node, and how the Rundeck host can reach every target through your network controls. Each node needs a reachable SSH endpoint and an account with only the privileges its jobs require. Expect the largest effort in the node inventory and key management rather than in the Rundeck install itself. Confirm with PagerDuty how Runbook Automation handles credential storage and any network path changes in its self-hosted and SaaS forms, since those details affect your security review.
What should we request in a quote?
Ask for a written scope that lists each Rundeck version and edition in use, the target deployment form (self-hosted or SaaS), the database platform and version from the supported list, the number of jobs, nodes and integrations, and the authentication and access control model. Request a clear split of PagerDuty licensing from implementation work, a list of which features are included in each edition, and the acceptance criteria for cutover. For DeployOpen, the quote follows from that written scope, and the engagement is typically fixed-scope with deliverables and timelines agreed before work starts. Ask both vendors to state what is one-time and what recurs each year.
Which Rundeck version should a new install target?
Rundeck v6.2.1 was published on September 9, 2026, with 6.3.0 release candidates following, according to the Rundeck GitHub releases page. Choose a version that your database and Java 17 runtime support, then check the release notes before upgrading an existing install. Teams that pin an older version should plan an upgrade path and test their jobs against the new release. Confirm the current stable version and the support window for your chosen edition with PagerDuty before you commit to a platform baseline.
How DeployOpen scopes, delivers and supports either Rundeck edition
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so Rundeck runs in your cloud account, data center or air-gapped network. Whether you stay on Rundeck Open Source or evaluate Runbook Automation, the work starts with a written scope that fits your node count, identity setup and audit needs.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which node groups, job types and access rules Rundeck must cover for your teams.
- Ask for a quote built from that scope, since DeployOpen does not publish a price list.
How we build
- Installation covers the database choice, moving off the embedded H2 default for production, and the supported Java runtime.
- Integration work covers authentication, the resource model and option data from your existing sources.
- Testing covers job execution over SSH with public-key authentication and access control checks for each role.
How we hand over
- Documentation describes the deployed configuration, job definitions, access rules and backup procedure in your own terms.
- Handover covers operator training on the web console, command line tools and web API used by your team.
- Confirm with your team which deliverables, such as runbook content or evidence for audits, the written scope includes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope work.
- Upgrade planning checks each Rundeck release against your databases, Java runtime and custom integrations before rollout.
- Ask whether a retainer or a Runbook Automation subscription from PagerDuty matches the support model your team needs.
