Deploy & run

One workflow package runs on the Boardwalk platform or your own self-hosted server without changing. This page covers the path most authors take: validate locally, then deploy and run on Boardwalk.

Iterate

boardwalk check validates the package locally, with no network and no account: the descriptor validates against the schema, the entry compiles, and every import resolves. boardwalk deploy with --run then ships it, triggers a real run on the platform, waits, and prints the result to your terminal. This is the tight loop you write in:

boardwalk check .
boardwalk deploy . --org your-org --run --input '{ "issue": 123 }'

Exit code is 0 on success, 1 on failure, so it drops straight into a script or a test. The two commands stay distinct: deploy is the only one that ships code, and boardwalk run <slug> runs whatever is already deployed without reading your disk at all, so it works from any directory on any machine with a login.

Deploy

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

boardwalk login
boardwalk deploy . --org your-org

A deploy builds the package into one artifact, uploads it, and finalizes the version; the server derives the input and output schemas from your runfunction's types and returns any derivation warnings, printed right there. A deploy that would create a new workflow asks first; every later deploy updates the same workflow as a new version. Deploying never starts a run; it just publishes the new version, and the next trigger uses it.

The org comes from the deploy context, resolved deterministically; it is never guessed:

1. --org wins,
2. else a single-org credential's scope,
3. else the project's local .boardwalk/ link,
4. else a hard error.

Trigger a run

A deployed workflow runs whenever a trigger fires: a cron schedule (which fires on its own once the workflow is deployed, with nothing else to wire up), an inbound webhook, or a manual start. Start one manually three ways:

• CLI: boardwalk deploy . --org your-org --run deploys and triggers in one step, then waits for the result.
• 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 with a streamed event log. While a run is in flight the dashboard live-tails it over SSE; afterward the same log replays. For the run lifecycle, the event model, the channels, and watches, see Runs & observability.

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