DOCSBeta
8Log in

Overview

Boardwalk runs agent workflows: TypeScript or Python programs that call models, run on schedules or webhooks, and keep a permanent record of every run. A workflow is plain code, so you author it in your own editor, with your own packages and tests, and ship it with one command.

Install the CLI

One command installs the CLI, logs you in, and wires up the coding agent you already use. It detects your agent (Claude Code, Codex, Cursor, OpenCode, OpenClaw), installs its Boardwalk plugin and the control-plane MCP server, and never touches files in your project.

npx @boardwalk-labs/setup

Prefer to do it by hand? npm install -g @boardwalk-labs/cli then boardwalk login; the CLI reference has every command and flag. boardwalk check works with no account at all, so you can validate a workflow before you sign up.

What Boardwalk is

The control plane for agent workflows: the place your org builds, versions, triggers, and runs them. The CLI (@boardwalk-labs/cli) and SDK (@boardwalk-labs/workflow) are open source (MIT), and the same program runs identically under two engines: a self-hosted server and Boardwalk itself. Start with Concepts for the handful of nouns the rest of the docs use.

The shape of a workflow

A workflow is a small package with two parts: a run function the platform calls, and a workflow.jsonc descriptor that tells the platform how to deploy it. No YAML pipelines, no node editor, no framework to subclass.

src/index.ts
import { agent } from "@boardwalk-labs/workflow";

export default async function run(): Promise<string> {
  return agent("Write a haiku about a boardwalk at sunrise.");
}
workflow.jsonc
{
  "$schema": "https://boardwalk.sh/schemas/workflow.json",
  "slug": "haiku",
  "triggers": [{ "kind": "manual" }]
}

The platform calls run(input, context)with the trigger's payload, and whatever the function returns is the run's output: persisted, typed, and handed to whoever called it. Type the input and the return and the deploy derives their schemas straight from your native annotations, so the dashboard's run form and other callers know the shape without a schema written by hand. Capabilities (agent(), secrets.get, sleep, workflows.call) are ordinary imports. The descriptor is deployment policy the control plane reads as data (triggers, permissions, budget) without ever executing your code. Python is first-class: point entry at a .py file and export a module-level run. See Writing workflows for the full model.

The author loop

With the CLI installed, write, check, and ship from your terminal:

boardwalk init my-workflow       # scaffold the package
boardwalk check my-workflow      # validate it locally, no account needed
boardwalk deploy my-workflow --org your-org --run   # ship it, then run it once

boardwalk init scaffolds the package (add --python for the Python shape). boardwalk check validates the program and its descriptor locally. boardwalk deploy ships it, and --run fires it once and prints the result back to your terminal. Afterwards boardwalk run <slug> runs the deployed workflow from anywhere, with no local copy needed, and boardwalk runs <id> --logs replays any run later. Once deployed, a cron or webhook trigger fires the workflow on its own, and every run gets a live tail and a permanent record.

Where to next