Configuration overview

RunWisp reads one file, runwisp.toml. It defines everything that runs; the Web UI and REST API can trigger runs but never change the config. After an edit, run runwisp reload.

[defaults]
timeout = "1h"

[tasks.backup-db]
cron = "0 3 * * *"
run  = "pg_dump app | gzip > /backups/app.sql.gz"

[services.worker]
instances = 2
run       = "node worker.js"

[notifiers.slack-ops]
type        = "slack"
webhook_url = "${SLACK_URL}"

Table	What it holds
[tasks.<name>]	Commands that run on a schedule or by hand, then exit.
[services.<name>]	Long-running processes RunWisp keeps alive.
[compose.<alias>]	Services imported from a docker-compose.yml.
[defaults]	Fallback values for every task and service.
[daemon]	Daemon-wide settings: timezone, TLS, metrics, included files.
[storage]	Disk limits for run logs.
[notify]	Daemon-wide notification settings.
[[route]]	Rules that send run events to notifiers.
[notifiers.<id>]	One outbound channel each. See Notifications.

Any string value can read an environment variable or a file with ${VAR} or ${file:path}.

The config path, data directory, and listen address are command-line flags, not config keys.

Editor support and validation

Start the file with a #:schema line and editors with TOML support (Even Better TOML, taplo) autocomplete and check it as you type. Files RunWisp creates already have it.

#:schema https://docs.runwisp.com/config.schema.json

runwisp validate   # check runwisp.toml exactly like daemon startup does
runwisp schema     # print the JSON Schema