RunWisp
Comparison · vs Rundeck

RunWisp vs Rundeck: when you need a scheduler, not a platform.

Rundeck is runbook automation: a Java service that runs jobs over SSH across a node inventory, with ACLs, key storage and workflows. RunWisp is a single binary that runs scheduled jobs and services on the machine it's installed on. One is built for an ops team, the other for a person with a few servers.

Quick start → Star on GitHub
Verdict

Should you switch?

The 10-second version. Skim, decide, scroll down for the receipts.

Switch to RunWisp if

  • You installed Rundeck to run a dozen cron jobs and now maintain a JVM and a database.
  • Your jobs run on the box they're scheduled on, not over SSH to others.
  • The open-source edition's 8 GB RAM minimum is more than the server you're scheduling on.
  • You want missed-run alerts and job queueing without a commercial licence.
  • You also need long-running services supervised.
  • Regular cron syntax beats Quartz's seconds field and ? placeholders.

Stay on Rundeck if

  • You run the same job across many nodes selected by tags.
  • Different teams need different rights, written as ACL policies.
  • Operators run self-service runbooks with options, without shell access.
  • Jobs are multi-step workflows with error handlers.
  • You need SSH and WinRM execution, Windows nodes, or key storage for credentials.
Head to head

Yes / no, at a glance

Yes / no — and both columns win on something.

Capability Rundeck (open source) RunWisp
Web UI + run history + logs ✓ ✓
Retries + timeouts ✓ ✓
Jobs as code ✓YAML / XML import ✓runwisp.toml is the config
Job options / parameters ✓ ✓typed params
REST API + CLI ✓ ✓
Single binary, no runtime ✗Java 17+ ✓
No external database ~H2 is test-only ✓embedded SQLite
Runs on a small VPS or Pi ✗8 GB RAM minimum ✓~30 MB idle
Standard 5-field cron ✗Quartz syntax ✓
Missed-run detection ~commercial ✓
Queue instead of skip on overlap ~commercial ✓skip / queue / kill
Slack / Telegram / Discord built in ~plugins ✓
Long-running services ✗ ✓
Terminal UI over SSH ✗ ✓
Run on many nodes over SSH ✓node inventory ✗local only
ACL / role-based access ✓ ✗one password
Multi-step workflows + error handlers ✓ ✗
Key storage for credentials ✓ ~secrets_file / ${file:}
Windows nodes ✓WinRM ✗Linux / macOS / WSL
Trade-offs

Pros & cons

What Rundeck does better

  • Runs a job across many nodes, picked by name or tags, over SSH or WinRM.
  • ACL policies per project, job and node, with LDAP login.
  • Self-service runbooks: an operator picks options in a form and clicks Run, without shell access.
  • Workflows with steps, error handlers and job references.
  • Key storage for SSH keys and passwords, and a large plugin ecosystem.
  • Backed by PagerDuty, with a commercial edition for SSO, HA clusters and support.

What RunWisp adds

  • One static binary, about 30 MB of RAM idle, with SQLite and the web UI built in. No JVM, no database server to run.
  • Installs in seconds with curl, Homebrew or Docker, on a VPS, a Raspberry Pi, a Mac or WSL.
  • Plain 5-field cron, with an optional seconds field and per-task timezone.
  • catch_up and missed-run alerts, and on_overlap = "queue", with no licence. In Rundeck these are commercial features.
  • Slack, Discord, Telegram, ntfy, Gotify, Pushover, email and webhooks with no plugins, and repeat alerts grouped.
  • Supervises long-running services with restarts and health checks in the same file.
  • The TOML file is the live config, not an import. Edit, review, runwisp reload.
  • A TUI over SSH as well as the web UI.
The simple case

The simple case

A nightly backup at 03:00. Rundeck's job definition is loaded into its database; RunWisp reads the file directly.

Rundeck job (YAML) 
# nightly-backup.yaml: import with rd jobs load, or via the GUI
- name: nightly-backup
  loglevel: INFO
  scheduleEnabled: true
  schedule:
    crontab: '0 0 3 ? * * *'      # Quartz: seconds first, ? required
  sequence:
    commands:
      - exec: /usr/local/bin/backup.sh
runwisp.toml 
# runwisp.toml
[tasks.nightly-backup]
cron = "0 3 * * *"
run  = "/usr/local/bin/backup.sh"
Production-grade

The version that runs in prod

Same backup, hardened. Rundeck runs it on db01 over SSH from a central server. RunWisp runs on db01 itself. If you have one or two such servers, the second model has fewer moving parts. If you have fifty, the first one starts to pay off.

Rundeck job (production) 
- name: nightly-backup
  description: Snapshot the data volume off-site
  loglevel: INFO
  scheduleEnabled: true
  schedule:
    crontab: '0 0 3 ? * * *'
  multipleExecutions: false
  timeout: 55m
  retry:
    retry: '2'
    delay: 30s
  nodefilters:
    filter: 'name: db01'
  notification:
    onfailure:
      - email:
          recipients: '[email protected]'
  sequence:
    keepgoing: false
    strategy: node-first
    commands:
      - exec: /usr/local/bin/backup.sh
runwisp.toml (production) 
# runwisp.toml on db01 itself
[tasks.nightly-backup]
description    = "Snapshot the data volume off-site"
cron           = "0 3 * * *"
on_overlap     = "skip"
timeout        = "55m"
retry_attempts = 2
retry_delay    = "30s"
retry_backoff  = "exponential"
keep_runs      = 60
notify         = ["email-ops", "slack-ops"]
run            = "/usr/local/bin/backup.sh"
Migration

Migration cheat sheet

Rundeck job YAML on the left, runwisp.toml on the right.

Rundeck RunWisp
schedule.crontab: '0 0 3 ? * * *' cron = "0 3 * * *": drop the seconds and year, ? becomes *
sequence.commands[].exec run =; several steps become one script or a && b
timeout: 55m timeout = "55m"
retry.retry + retry.delay retry_attempts + retry_delay + retry_backoff
multipleExecutions: false on_overlap = "skip" (or queue / kill)
Job options params, filled in from the UI, CLI or API
notification.onfailure notify = ["email-ops"]
Run Job webhook / API token hook_tokens, scoped to one task
Key storage secrets_file or ${file:/run/secrets/...}, masked in logs
nodefilters No equivalent. Install RunWisp on each node that runs jobs.
Gotchas

Gotchas

No remote execution

RunWisp runs commands on its own machine. To act on another host you'd write ssh db01 ... in run, and RunWisp has no node inventory to pick hosts from. If “run this on every web node” is your daily work, Rundeck is the right tool.

One password, no roles

A RunWisp daemon has one password. Anyone who has it can run, stop and restart every task, though nobody can change task definitions through the UI. For CI, hook_tokens grant one task's actions without the password. Per-team permissions are out of scope.

Quartz cron doesn't paste in

Rundeck schedules use Quartz: a seconds field first, an optional year last, and ? in day-of-month or day-of-week. Convert each schedule by hand. Check the result with our cron checker.

Move the small stuff first

Teams often keep Rundeck for runbooks and move the boring schedules (backups, cleanups, report generation) to RunWisp on the hosts where they run. The two don't conflict.

FAQ

FAQ

What is a lightweight alternative to Rundeck?
If your jobs mostly run on the machine that schedules them, RunWisp: an open-source cron replacement that ships as a single binary, with a web UI, run history, retries and alerts, and about 30 MB of RAM idle. It doesn't do remote execution, RBAC or workflows. If you need those without a JVM, look at Cronicle or xyOps for multi-server scheduling, or Dagu for workflows.
How much RAM does Rundeck need?
Rundeck's system requirements list 8 GB of RAM, a 4 GB JVM heap and 2 CPUs as the minimum for the open-source edition, and 16 GB for the commercial self-hosted edition. It also wants MySQL, MariaDB, PostgreSQL, SQL Server or Oracle in production; the embedded H2 database is for testing. RunWisp idles around 30 MB with SQLite built in.
Is Rundeck free?
The open-source edition is Apache-2.0 and free. SSO, HA clustering, job queueing, missed-run handling, calendars and failed-job resume are in PagerDuty's commercial Runbook Automation editions. RunWisp is GPL-3.0 with every feature in the free binary; it also does much less than Rundeck.
Can RunWisp run jobs on other servers?
Only by running ssh in the command, which RunWisp doesn't manage for you. The intended setup is one RunWisp per server, each running its own jobs. You can trigger a task on another server's RunWisp from CI or a script with runwisp run --url, and get its output and exit code back.
Can I export Rundeck jobs to RunWisp?
There's no automatic converter. Export your jobs as YAML from Rundeck and map them using the table above: crontab becomes cron with the seconds field dropped, exec becomes run, timeout and retry carry over. Multi-step jobs become a script.
More comparisons: vs Cronicle vs Dagu vs cron what RunWisp is, in one page →
Get started
GPL 3.0 · no accounts · free to self-host

Schedule the jobs without running a platform.

Install one binary on the box that runs the jobs, write a runwisp.toml stanza per Rundeck job, and watch the first run land with its exit code and output.

Install in 30 seconds
curl -fsSL https://get.runwisp.com | sh
Quick start → Star on GitHub