Workflows
A workflow is a named, reusable run configuration: run this selection of the graph, against this branch, with these dependency options — on a schedule, or on demand. It’s the hosted home for both your scheduled production runs and one-click “Run now” runs.
Manage them from a project’s Workflows page.
Fields
Section titled “Fields”- Name — a label for the workflow.
- Branch — the git branch the run compiles and executes (e.g.
main). - Tags / Actions — the selection. Empty runs the full graph; otherwise only actions matching
the chosen tags (
--tags) and/or the explicitly chosen actions (--actions, byschema.name). Tags and actions compose as a union. The dropdowns are populated from the branch’s compiled catalog — use Refresh to recompile it after the branch changes (the editor shows which commit the catalog is from). - Include dependencies — also run the upstream actions the selection depends on
(
--include-deps). Needs a non-empty selection. - Include dependents — also run the downstream actions that depend on the selection
(
--include-dependents). Needs a non-empty selection. - Environment — an optional named environment (compilation overrides).
- Schedule — optional. A standard 5-field cron expression, e.g.
0 6 * * *(daily at 06:00), evaluated in the workflow’s timezone. Leave it off for an on-demand-only workflow.
How it runs
Section titled “How it runs”Workflow runs execute against the real warehouse — their writes are the point, and they persist. (Pull-request CI is different: it runs on a disposable database branch that’s destroyed afterwards. A workflow run is the production counterpart.)
For Supabase warehouses connected via OAuth, no database password is ever stored: each run mints a
short-lived, single-purpose database login through your Supabase connection, uses it for the run,
and disables it immediately after. Objects it creates are owned by postgres, exactly as if you’d
run the CLI yourself.
Scheduled workflows fire from a periodic tick; Run now enqueues the same run immediately. If a workflow’s previous run is still going, the tick skips that firing rather than overlapping it. Every firing appears in the project’s run history tagged with its workflow, with full per-action detail.
Releases — pinned compilation snapshots
Section titled “Releases — pinned compilation snapshots”By default a workflow compiles the branch head at run time. Setting Run from → Latest release pins it to a release: a frozen compilation of the branch (and environment) at an exact commit. Pinned workflows keep running that exact code even as the branch moves — until a new release is cut.
- Cut release on the Workflows page compiles the branch head into a new snapshot (per environment, since environment overrides change the compiled SQL).
- Pushes to a pinned branch cut a release automatically — merging to
mainrefreshes what your scheduled workflows run, Dataform-release-config style. - Each release records the commit, action count, and the full compiled graph for audit; every run links back to the release it executed.
Selection mirrors the CLI
Section titled “Selection mirrors the CLI”A workflow is just a saved version of a run you could do by hand:
sqlanvil run . --tags daily --include-dependents --environment prodTag/action selection and both dependency-expansion flags behave exactly like the CLI’s.