# Rundeck: Self-Service Runbook Automation With a Web Console, CLI and WebAPI

> Rundeck by PagerDuty is an Apache-2.0 runbook automation service written mainly in Groovy. It gives named users a controlled way to run existing scripts and tools across a set of nodes, and it ships as deb, rpm or war packages.

**rundeck/rundeck** — Enable Self-Service Operations: Give specific users access to your existing tools, services, and scripts

- Repository: https://github.com/rundeck/rundeck
- Website: http://rundeck.org
- Stars: 6,320 · Forks: 988
- Language: Groovy
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/rundeck-rundeck

## The problem Rundeck solves: giving specific users access to existing tools

Most operations teams do not lack automation. They lack a safe way to hand it out. A shell script that restarts a service, a database migration, a deploy step: each one lives on someone's machine or in a repository, and running it means asking an operator who has the credentials. The README frames the project's purpose directly: it "lets you easily standardize tasks to improve operational quality by deploying automation across a set of nodes." The homepage tagline is narrower still, promising to "Give specific users access to your existing tools, services, and scripts."

That word, specific, is the whole point. Rundeck is not a configuration management system that decides what the desired state of a server should be. It is an execution and access layer. The unit of work is a job, and the repository topics list runbook, scheduler and audit alongside automation and orchestration. A job is defined once, given a name, and then run by people who may have no shell access to the target nodes at all. The audience is therefore operations, SRE and platform teams who already own scripts and want to stop being a human API for them.

## How Rundeck works: console, CLI and WebAPI over a node executor

The README describes three surfaces over one service: "a web console, command line tools and a WebAPI." A job is the central object. It contains the steps to execute, the nodes to execute them on, and the access rules that decide who may run it. The web console is where most users meet it; the CLI and the WebAPI are how the same jobs get triggered from a pipeline or another system.

The repository layout shows how the pieces are separated. The top level contains core/, rundeckapp/, rundeck-authz/, rundeck-storage/, rundeck-repository/, rundeck-data-models/ and grails-webhooks/. Authorization is its own module rather than a setting buried in the web tier, which matches the self-service framing: policy is a first-class concern. Execution against remote machines is pluggable. The examples directory lists example-java-nodeexecutor-plugin/, example-script-node-step-plugin/ and example-script-remote-node-step-plugin/, so the mechanism that reaches a node is something you can replace, not something fixed by the product.

Plugin types visible in examples/ cover a wide range: log filters, log plugins, notification plugins, audit plugins, execution lifecycle and job lifecycle plugins, storage and storage converter plugins, plus a json-plugin. That breadth is the design signature. Rundeck expects to sit in front of infrastructure it did not create, and to be extended at the points where it meets that infrastructure.

## Installing Rundeck and running a first job

The README does not carry install steps. It points at the install page instead: "Install Rundeck" links to docs.rundeck.com/docs/administration/install/installing-rundeck.html, and the download table offers deb, rpm and war packages through rundeck.com/downloads. Choose the format that matches your distribution; the war is the option when you want to deploy into an existing servlet container.

Building from source is documented in the README and is the path if you intend to work on the code rather than run it. The primary build is Gradle, and the stated requirements are Java 11 and NodeJs 18. The command below produces a war artifact at the path the README names.

```bash
./gradlew build
```

After that build, the README says the output is rundeckapp/build/libs/rundeck-X.Y.war. If you want a container image rather than a war, the repository has a Docker build that uses the war artifact and creates the rundeck/rundeck:SNAPSHOT image.

```bash
./gradlew :docker:officialBuild
```

The README notes two Gradle properties for that task: dockerTags adds extra tags, for example -PdockerTags=local,local-RUN-123, and jreVersion selects the JRE for the image, for example -PjreVersion=openjdk-17-jre-headless. Contributors without Cloudsmith access have an extra step before building: the README instructs them to delete the .npmrc and package-lock.json files in rundeckapp/grails-spa/packages/ui-trellis/ and in rundeckapp/grails-app/assets/javascripts/_package-manager/.

```bash
rm rundeckapp/grails-spa/packages/ui-trellis/.npmrc rundeckapp/grails-spa/packages/ui-trellis/package-lock.json
rm rundeckapp/grails-app/assets/javascripts/_package-manager/.npmrc rundeckapp/grails-app/assets/javascripts/_package-manager/package-lock.json
```

For UI work, the README defines a CORE_UI variable pointing at rundeckapp/grails-spa/packages/ui-trellis and runs npm scripts against it. Dev mode builds the core UI components and copies the artifacts into the running application's assets directory.

```bash
CORE_UI=rundeckapp/grails-spa/packages/ui-trellis
npm run --prefix "$CORE_UI" dev
```

Once the service is up, the first real use is a job that wraps a script you already run by hand. The README does not document the job-creation form or its fields, so treat the console itself as the source for that step. What the repository does tell you is that a job can be triggered from the web console, from the CLI, or over the WebAPI, which is the reason to define it as a job instead of leaving it as a script.

## Where Rundeck is the wrong tool

Rundeck is an execution layer, and it does not pretend to be a desired-state configuration manager. If your actual problem is that twenty servers have drifted from a baseline, Rundeck will run your remediation script on all twenty, but it will not tell you which twenty needed it or keep them converged afterwards. The repository's own topics list ansible, which is a hint about how it is usually deployed: as the thing that invokes configuration tooling under access control, not as a replacement for it.

There is a second boundary in the build requirements. The README states Java 11 and NodeJs 18 for the primary Gradle build. That is a real constraint on a team whose toolchain has moved past those versions, and it is worth checking against your environment before you plan a source build. The Docker build exposes a jreVersion property, which suggests the image's JRE is a choice you make rather than a fixed default, but the README does not state which value is used when you omit it.

Finally, the README is a developer-facing document. It covers building, UI tests, Storybook and contribution paths, and it defers installation and product behaviour to docs.rundeck.com. If you need a single page that explains how to install on Ubuntu or Windows, this repository is not that page; the install link is the pointer, and the rest is elsewhere.

## Rundeck compared with Ansible and Jenkins

The two comparisons people search for most are Rundeck vs Ansible and Rundeck vs Jenkins, and they fail in different directions.

Ansible describes the end state of machines and applies it. Its centre of gravity is the inventory and the playbook. Rundeck's centre of gravity is the job and the person allowed to run it. When Rundeck executes across nodes, it is dispatching work; when Ansible runs, it is converging state. The repository topic list includes ansible, and the natural arrangement is Rundeck as the front door and Ansible as one of the things behind it. Choosing Rundeck to replace Ansible means giving up idempotence and drift detection. Choosing Ansible to replace Rundeck means giving up the per-user access model and the audit trail around who ran what.

Jenkins is a build server that grew job scheduling. It can run shell steps on agents and it has credentials and permissions, so the overlap is real. The difference is intent: Jenkins models a pipeline that produces an artifact, with stages and a build history. Rundeck models an operational procedure that produces a change on a node, with an execution log and an approval-friendly access model. Teams that already run Jenkins often start by putting operational scripts into it, and the friction shows up when non-engineers need to trigger a restart without seeing the build UI. That is the gap Rundeck is built for.

## Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-22. The release cadence is visible in the tags: v6.2.1 on 2026-09-09, v6.2.0 on 2026-09-08, and v6.1.0 on 2026-08-03. Patch releases arriving a day after a minor release is a normal shape for a project that ships fixes quickly rather than batching them.

Upgrade cost is not documented in the README. It links to a Release Notes page at docs.rundeck.com/docs/history/ for version information, and that page, not this repository, is where you would look for migration steps between v6.1.0 and v6.2.x. The README is silent on rollback, on database schema changes between versions, and on whether the war, deb and rpm artifacts upgrade in place. Treat those as open questions to resolve from the documentation before you schedule an upgrade window.

The licence is Apache-2.0, and the README carries the standard notice with the copyright line "Copyright 2024 PagerDuty, Inc." Apache-2.0 permits commercial use and modification and includes a patent grant; it also requires that you keep the licence and notice files and state significant changes. The README's own text says the software is distributed "on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND." There is a SECURITY.md at the repository root, which is where vulnerability reporting is handled. None of this is legal advice; if you are embedding Rundeck in a product you ship, have counsel read the licence text itself.

## Conclusion

Adopt Rundeck if you already have scripts and tools that different teams keep asking operators to run by hand, and you want a web console, CLI and WebAPI in front of them with per-user access. Skip it if your problem is configuration convergence across a fleet: that is Ansible's job, and Rundeck is the layer that calls it. Before committing, check the install page at docs.rundeck.com for the package format that matches your distribution, confirm your JDK against the Java 11 build requirement in the README, and read the Release Notes page linked from the README for the changes in v6.2.1.

## FAQ

### What is Rundeck used for?

It is a runbook automation service that executes workflows across existing automations or automates previously manual procedures, according to the README. It standardizes tasks and deploys automation across a set of nodes, with a web console, command line tools and a WebAPI as the interfaces.

### Is Rundeck free to use?

The repository is licensed under Apache-2.0, which permits commercial use and modification under the terms of that licence. The README also links to rundeck.com/downloads for deb, rpm and war packages, and the project describes itself as open source.

### How does Rundeck work?

Jobs are defined and executed through a web console, command line tools or a WebAPI, and execution against remote nodes goes through a node executor that can be replaced with a plugin. The repository ships example node executor and script step plugins under examples/.

### What is a Rundeck job?

A job is the unit that carries the steps to run and the nodes to run them on, and it is what the web console, CLI and WebAPI all trigger. The README describes the product as standardizing tasks and deploying automation across a set of nodes rather than defining a job's fields.

### How do I install Rundeck?

The README does not contain install steps. It links to docs.rundeck.com/docs/administration/install/installing-rundeck.html and offers deb, rpm and war downloads through rundeck.com/downloads. Building from source uses Gradle with Java 11 and NodeJs 18.

## Sources

- [License: Apache-2.0](https://github.com/rundeck/rundeck/blob/main/LICENSE)
- [Project website](http://rundeck.org)
- [README](https://github.com/rundeck/rundeck/blob/main/README.md)
- [Releases](https://github.com/rundeck/rundeck/releases)
- [rundeck/rundeck on GitHub](https://github.com/rundeck/rundeck)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rundeck-rundeck