Docs
1Log in

Deploy & run

One workflow file runs in three places without changing: boardwalk dev on your laptop, the Boardwalk platform, or your own self-hosted server. This page covers the path most authors take: iterate locally, then deploy and run on Boardwalk.

Iterate locally

boardwalk dev executes the file right now and streams the run log. No deploy, no account; secrets come from .env. This is the tight loop you write in:

boardwalk dev . --input '{ "issue": 123 }'

Exit code is 0 on success, 1 on failure, 130 on Ctrl-C, so it drops straight into a script or a test.

Deploy

boardwalk login authenticates in the browser once; then boardwalk deploy ships the workflow to your org:

boardwalk login
boardwalk deploy . --org your-org

The first deploy creates the workflow and writes a .boardwalk/ link file in the project. Every later deploy updates the same workflow as a new version (even if you rename it), so --orgisn't needed again. Add --dry-run to print the plan (create vs. update) without writing. Deploying never starts a run; it just publishes the new version, and the next trigger uses it.

Trigger a run

A deployed workflow runs whenever a trigger fires: a cron schedule, an inbound webhook, or a manual start. Start one manually three ways:

  • CLI: boardwalk run . --org your-org deploys and triggers in one step, then waits for the result (--no-wait returns immediately; --input supplies a payload).
  • Dashboard: the Run button on the workflow, with an optional input.
  • Another workflow: workflows.call() / workflows.run() from a program.

Watch a run

Every run is a permanent record: status (queued → running → completed / failed / cancelled), the streamed event log (phases, agent turns, tool calls, your output), token and cost usage, and any artifacts. While a run is in flight the dashboard live-tails it over SSE; afterward the same log replays. Cancel a queued or in-flight run with boardwalk cancel <runId> or the dashboard.

Schedules

A crontrigger fires on its own once the workflow is deployed. There is nothing else to wire up. The dashboard's Schedules view lists every cron across the org, the next fire time, and recent runs. To change a schedule, edit meta.triggers and redeploy.

Deploy from CI

For non-interactive environments, skip the browser login and pass an org API key (created in Settings → API keys) via the BOARDWALK_API_KEY environment variable, or the --token flag. A common setup runs boardwalk check on every PR and boardwalk deploy on merge to main:

# in CI, with BOARDWALK_API_KEY set as a secret
boardwalk check .
boardwalk deploy . --org your-org