Rundeck earned its place: node-targeted jobs, a live per-node monitor, and finely grained access control. SwitchTender delivers that job from one static Go binary instead of a JVM with an external database behind it. Terraform and OpenTofu run as first-class steps alongside Ansible, Bash, PowerShell, Python, and Go. Approval gates are enforced by policy in the core, the drag-and-drop workflow editor is free rather than commercial, and every run lands in a hash-chained audit trail a third party can verify offline. State is one SQLite file, with Postgres optional.
Rundeck is a capable runbook engine. These are the walls teams hit as governance and tooling needs grow.
Rundeck runs on a Java virtual machine, and its bundled H2 datastore is documented as unsuitable for production, so a real deployment adds an external database. Its published minimum is 8 GB of RAM and 2 CPUs. SwitchTender is one static Go binary and one SQLite file, and Postgres is optional rather than required.
Rundeck runs Ansible and generic scripts, but has no Terraform or OpenTofu step type, so infrastructure changes live outside the runbook. SwitchTender runs Ansible, Terraform, OpenTofu, Bash, PowerShell, Python, and Go as first-class tools in one plan, with drift detected from a dry run.
Rundeck's workflow visualization and its ACL GUI editor sit in the commercial tier, and approval gates are not documented in the free one. SwitchTender ships the drag-and-drop workflow editor, policy-enforced approvals, and a tamper-evident, signed audit trail in the core, free to self-host.
Every claim below was checked against Rundeck's own documentation at version 6.0.1, on 10 August 2026. Rundeck's current release is 6.1.0, which these claims have not been re-checked against. The full six-way table with sources is on the comparison page.
| Capability | SwitchTender | Rundeck |
|---|---|---|
| Runs without a JVM | ||
| Production datastore built in | SQLite, Postgres optional | H2, not for production |
| Live per-host view | Host-by-task matrix | Per-node, per-step monitor |
| Tools | Ansible, Terraform, OpenTofu, Bash, PowerShell, Python, Go | Ansible and scripts, no Terraform step |
| Tamper-evident, signed audit | ||
| Verifiable offline by a third party | ||
| Enforced approval policies | Commercial Runbook Automation only | |
| Visual workflow editor in the free tier | Engine free, visualization commercial | |
| Fine-grained access control | Per-object grants | ACL policy files; GUI editor commercial |
| Fleet memory: flaky hosts, trends | ||
| Drift detection from a dry run | ||
| Duration-balanced job splitting | ||
| Minimum published footprint | One binary, one file | 8 GB RAM, 2 CPU |
Checked against Rundeck’s own documentation on 2026-08-10, for Rundeck 6.0.1. Rundeck was at 6.1.0 on 2026-09-07. A comparison decays the day it is written, so check a row against the current release before you rely on it. Full table and sources.
Honesty first. Rundeck's live per-node, per-step monitor is a peer capability it has shipped for years, not a gap. Its file-based ACL model applies regex-matched, deny-first policy to authorization as a whole, which is more granular than SwitchTender's approval policy files in that one respect. It has more than a decade of production history, a large plugin ecosystem, and a commercial vendor behind it. switchtender import rundeck reads a job export and creates the equivalent templates, surveys, and schedules, converting the Quartz recurrence as it goes, but a job arrives as a Bash template rather than an Ansible one, so a job you want fanned across an inventory is rewritten by hand afterward.
One binary, no JVM, nothing else to install. Point it at the same hosts your Rundeck jobs target and compare the run views side by side.
brew install kordloom/tap/switchtenderswitchtender serveThe get started guide covers prebuilt binaries for Linux, macOS, and Windows with published checksums, and go install.
The three asked most often when somebody is comparing this against what they already run.
No. It reaches the machines it manages over SSH, the same way Ansible does, and installs nothing on them. There is no per-host daemon to deploy, patch, or account for. You run the one server binary. Worker processes for extra throughput are a Team feature, and they are pool members rather than agents belonging to a host.
All three, resolved at launch rather than copied into this database. Vault dynamic secrets go further: a short-lived credential is minted for each run and revoked when the run ends. AWS and Azure both authenticate from an instance role or managed identity with no stored key, and anything else resolves through a command whose output is the secret.
Yes, and it is what pipelines are for here. Steps mix tools freely on a dependency graph with parallel branches, built on a drag-and-drop canvas. The approval is not a convention somebody can skip: a policy decides which runs are held, the core enforces the hold, and the approval binds to the exact plan reviewed, so a run cannot be approved as one thing and executed as another.