Open-source engine

The Boardwalk runtime is open source (Apache-2.0). One docker rungives you the whole single-node control plane on your own hardware (cron scheduling, runs that hold through waits, run history) with no Boardwalk account and no Boardwalk cloud. The workflow package is identical to the one you'd deploy; a shared conformance suite keeps the engines honest.

This is one of three ways to run Boardwalk; the comparison lives at Choosing where runs execute. Nothing here reaches Boardwalk: no account, no Boardwalk cloud, and the only outbound traffic is whatever your own workflows make. If the requirement is strictly that data cannot leave your network, this is the air-gappable answer.

Run the server

docker run -v ./data:/data -p 8080:8080 ghcr.io/boardwalk-labs/boardwalk

It's a long-lived process: it schedules cron triggers, accepts webhooks, runs workflows, and keeps history. The mounted data directory (/data) holds everything that persists (the SQLite database, per-run working directories, and artifacts), so back that up, not the container.

This surface has no authentication beyond webhook auth, so it binds to localhost by default and warns if you bind it wider. Put it behind your own auth / network before exposing it.

Add workflows

The server loads built workflows from its workflows directory on boot. Compile a package to a single deployable file with the CLI, drop it in, and restart:

boardwalk build ./my-workflow        # → my-workflow.mjs
cp my-workflow.mjs ./data/workflows/  # the default BOARDWALK_WORKFLOWS_DIR
# restart the container to load it

Each built file is one workflow: the package's run entry bundled with its workflow.jsonc descriptor (the SDK left external). A git checkout of your workflows mounted at the workflows directory is a clean way to manage a fleet.

Inference & secrets

Self-hosting is bring-your-own by default. You supply the model access and the credentials:

Your own models: declare providers with BOARDWALK_PROVIDERS (a JSON table of OpenAI-compatible endpoints) and name them in agent(..., { provider }). A local Ollama or any vendor key works. Set BOARDWALK_DEFAULT_MODEL for the model used when a call omits one.
Boardwalk managed inference: set BOARDWALK_API_KEY to a Boardwalk org key and the default boardwalk provider routes through the managed lane. Handy if you want hosted inference without hosting the rest.
Secrets: secrets.get() and provider API keys resolve from an .env file (BOARDWALK_ENV_FILE, default <data-dir>/.env). Your hardware, your values.

See Inference for how agent() resolves a model.

Configuration

Everything is environment variables:

Variable	Default	What it sets
`BOARDWALK_DATA_DIR`	`/data` in Docker	Where everything lives: SQLite DB, run dirs, artifacts.
`BOARDWALK_WORKFLOWS_DIR`	`<data-dir>/workflows`	Directory of built workflows (`.mjs`/`.js`) loaded on boot.
`BOARDWALK_HOST` / `BOARDWALK_PORT`	`0.0.0.0` in Docker / `8080`	Bind address and listen port.
`BOARDWALK_DEFAULT_MODEL`	none	Model used when `agent()` omits one.
`BOARDWALK_PROVIDERS`	none	JSON table of OpenAI-compatible providers.
`BOARDWALK_ENV_FILE`	`<data-dir>/.env`	`.env` backing `secrets.get` and provider keys.

Open-source engine vs. Boardwalk

The runtime is the same; the platform adds the operational layer you'd otherwise build, and the same workflow package moves between them unchanged, so leaving is always possible, which is the point (the comparison is at Choosing where runs execute).

Local is free, forever

Nothing on this page requires a plan, an account, or a time limit. The hosted platform is a separate offer, and it also starts free; plans and rates are on the pricing page.