Concepts
A quick mental model of how Cronable is put together. Everything else in these docs builds on these five ideas.
Jobs are config files
Every automation is a job, and every job is a small YAML file:
<jobs-repo>/<group>/<id>.yaml. The YAML is the source of truth — the UI edits it through the
API and the change round-trips back to the file. You can edit jobs in the UI or in your editor; both
end up as the same versioned files.
The group is just the folder, used to organize jobs (and to scope things like import/export). A
job’s id is unique within the whole install.
Jobs never contain secret values — they reference secrets and credentials by name
({{ $secrets.X }}, {{ $credentials.Y }}), and the real values live encrypted, outside the repo
(see Secrets & credentials).
The graph is derived, not stored
The canvas shows your jobs as a DAG (a draggable graph). The edges aren’t a separate thing you manage — they’re derived from how jobs chain: when job B is configured to run after job A, an edge A → B appears. Delete the chaining and the edge disappears. Node positions are the only graph-specific state (saved separately); the shape of the graph always reflects the jobs themselves.
Three ways a job starts
A job runs when any of its start conditions fire:
- On a schedule — one or more time points (e.g. every hour, weekdays at 9am). See Scheduling.
- After a parent — chained off another job’s outcome (on success, on failure, or either). This is what builds the DAG, and it’s how a pipeline flows from step to step.
- From a trigger — an external event: an inbound webhook, a new email, a file appearing, a calendar event approaching, a Telegram message, a new spreadsheet row. See Triggers.
A single job can combine these — e.g. a job that runs on a schedule and whenever a webhook fires. A job with none of them only runs when you trigger it by hand.
Data flows down the chain
When a job runs after a parent, it receives the parent’s output as {{ $parent }} — its text,
its structured json, or (on the failure path) its error. That’s how one step passes a value to
the next: an HTTP job fetches data, a code job reshapes it, an email job sends it. Alongside
$parent, expressions can read $vars, $secrets, $credentials, $env, and $now. See
Expressions & data flow.
Three parts, one machine
Cronable runs entirely on your machine as two long-lived processes plus your jobs repo:
- The daemon — the engine. It owns every schedule timer, runs the jobs (as child processes or in-process API calls), holds the encrypted secrets, streams live logs, and is the sole writer of the job files. Run it under a process manager so it’s always up.
- The web UI — a dashboard that talks only to the daemon (never runs jobs itself). It streams live updates over SSE, so runs and logs appear as they happen.
- The jobs repo — a plain git repository holding the job YAML. It can two-way sync with a remote (both directions off by default) so your automations are versioned and portable. See Git sync in the Operations guide.
Runtime state — run history, run output, encrypted secrets — lives in the daemon’s own database, not in the jobs repo. So the repo stays a clean, shareable description of what your automations are, while the daemon keeps track of what happened.
Where to go next
- Quickstart — install and create your first job.
- Job reference — every job type and its fields.
- Executions & run history — watch, filter, re-run, and download run logs.