RunWisp

Single-binary cron job manager and process supervisor with a web dashboard, terminal UI, run history, and failure alerts.

Open source alternative to:

PM2

Google Cloud Scheduler

AWS EventBridge Scheduler

Overview Releases

1 / 2

RunWisp is a self-hosted scheduler and process supervisor written in Go. You describe both cron-style tasks and long-running services in a single runwisp.toml, and one binary runs them without Python, Node.js, or an external database. Every run is recorded in embedded SQLite with its exit code, duration, timestamps, and captured stdout/stderr, and you can follow logs live or replay past runs from the web dashboard, the terminal UI, or the REST API.

Tasks get real cron syntax plus what crond never had: missed-run catch-up, jitter, timeouts, retries with backoff, and queue, skip, or kill policies for overlapping runs. Services get instance counts, restart backoff, crash recovery, and graceful shutdown, which is the supervisord job. Failures can go to Slack, Discord, Telegram, ntfy, Gotify, Pushover, email through SMTP or a local MTA, a generic webhook, or the in-app inbox, and the daemon exposes Prometheus metrics and SSE log streams.

Deployment is deliberately boring: a static binary plus a config file, installable from a shell script, Homebrew, deb/rpm packages, npm, or the official Docker image. RunWisp ships importers for cron, supervisord, systemd, docker-compose, and Ofelia, so a migration starts from the config you already have. The UI and API can trigger, stop, pause, and restart tasks but cannot edit task definitions; runwisp.toml stays the source of truth and can live in version control. That replaces the paid side of tools like PM2 Plus, Cronitor, and Rundeck for the local, single-host case, and it replaces crond and supervisord outright.

Frequently Asked Questions

Which platforms does RunWisp run on?

RunWisp runs on Linux and macOS. Linux builds are published as deb and rpm packages for amd64 and arm64, plus tarballs; macOS installs through Homebrew. The official Docker image ships Alpine and Debian variants for amd64 and arm64. Clients are the CLI, the terminal UI over SSH, and the web dashboard served by the daemon; there are no native desktop or mobile apps.

How does authentication work in RunWisp?

The CLI and TUI on the same machine talk to the daemon over a local control socket and need no password. The web UI and remote REST clients log in with one daemon password, taken from RUNWISP_PASSWORD or generated at boot, using a challenge-response exchange so the password is not sent over the wire. A separate viewer password grants read-only access, API tokens work for scripts, and RUNWISP_AUTH=off disables auth for trusted local setups. There are no per-user accounts, SSO, or 2FA.

Can I migrate an existing cron, supervisord, systemd, or docker-compose setup?

Yes. runwisp import cron converts a crontab, and runwisp takeover replaces cron itself in one command. Importers also exist for supervisord INI configs, systemd service and timer units, Ofelia jobs, and docker-compose files, where each compose service becomes a RunWisp service without editing the YAML. The docs walk through how each directive maps and which parts need a human decision.

Does RunWisp have an API or a CLI?

Both. The daemon serves a documented REST API with an OpenAPI description, including SSE endpoints for live logs and hook tokens for triggering, restarting, or stopping tasks from scripts and CI. The CLI covers daily operations and runwisp run --url can trigger a task on a remote instance and return its output and exit code. An OpenMetrics endpoint at /metrics can be scraped by Prometheus. Task definitions themselves cannot be changed through the API or UI; they stay in runwisp.toml.

What notification channels does RunWisp support?

Failure and missed-run alerts can go to Slack, Discord, Telegram, ntfy, Gotify, Pushover, any SMTP server or the local sendmail binary, a generic JSON webhook with custom headers, and the in-app notification inbox. Routes let you match events by kind, failure state, and task name so different tasks alert different channels. Each channel can be tested from the UI or config before you rely on it.

Visit RunWisp