Self-hosting

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, hold-and-pay run semantics, run history) with no Boardwalk account and no Boardwalk cloud. The workflow file is identical to the one you'd deploy; a shared conformance suite keeps the engines honest.

Where your data lives

Self-hosting is one of three ways to run Boardwalk, and which one fits comes down to how much has to stay inside your own network. The same workflow file runs unchanged in all three, so this is an operational choice, not a rewrite.

Model	Compute runs on	What reaches Boardwalk	Nothing leaves your network?
Boardwalk cloud hosted runners	Boardwalk's cloud	Code, run input/output, logs, artifacts, and model context. Secrets live in the managed vault and are redacted from model context.	No, this is the managed model.
Self-hosted runners your compute, our control plane	Your machines	The run executes on your hardware, so code and the working tree stay local. The runner still connects outbound to stream run events, logs, and (by default) artifacts to the control plane.	Partly: compute stays put, but telemetry still flows.
Fully self-hosted the open source engine	Your infrastructure	Nothing. No account, no Boardwalk cloud. The only outbound traffic is whatever your own workflows make.	Yes, this is the air-gappable answer.

So if the requirement is strictly that data cannot leave your network, the answer is the fully self-hosted open source engine, which the rest of this page covers. Self-hosted runners keep compute and the working tree on your hardware but still talk to the hosted control plane, so they answer "run it on our machines" rather than "air-gap it." Everything else is the managed cloud.

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 program 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 .mjs/.js file is one workflow (single-file, with 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.

Self-hosted vs. Boardwalk

The runtime is the same; the platform adds the operational layer you'd otherwise build. Self-hosting gives you single-node scheduling, runs, and history on your hardware. Deploying to Boardwalk adds orgs, roles, and audit; a managed secrets vault; managed inference with no keys; hosted runners with an egress boundary; the live-tail dashboard; and usage + billing. The same workflow file moves between them unchanged, so leaving is always possible, which is the point.

Local is free, forever

Nothing on this page requires a plan, an account, or a time limit. Build a workflow, run it with boardwalk devor this server, schedule it, keep its history, all on your own hardware with your own model key. That is the Free plan's whole shape: build and run locally, free, forever (open source). Subscribe to run hosted.

A subscription is what turns on the hosted side: durable runs on managed runners, triggers that fire in the cloud, managed inference with no keys, and self-hosted runners attached to the hosted control plane. Plans and rates are on the pricing page; how the limits behave is in Plans & limits. The same workflow file moves from your laptop to a plan unchanged.