flowwork is distributed as a single static binary. Installing and running it is the whole setup — there’s no database, container, or service to stand up separately.
Install & run
- Download the binary for your platform.
- Set your license key (from your account page).
- Run it.
export FLOWWORK_LICENSE_KEY=FW-XXXXX-XXXXX-XXXXX
flowwork # engine + API on :9010flowctl, the command-line client, is installed alongside and talks to the running engine.
What the first run sets up
On first launch the binary does everything needed to be ready:
- Brings up its own embedded Postgres on a local port and supervises it.
- Applies database migrations automatically.
- Generates and persists an encryption key for connector credentials (a
0600file in the data directory — no key to manage by hand). - Seeds a default workspace and user, so
flowctlworks immediately with no bootstrap step.
After that it serves the REST API under /api, exposes health probes, and binds a
machine slot by hardware fingerprint.
Released binaries run in desktop mode: the engine manages its own local database on your machine or sandbox. That’s the supported deployment today — there’s no external database or cluster to operate.
Data, health & shutdown
- Data directory — the embedded database and key file live under a per-user app data
directory (e.g.
~/Library/Application Support/flowwork/on macOS,%APPDATA%\flowwork\on Windows). Footprint is modest — on the order of ~100–150 MB on disk once the database is created. - Health endpoints —
GET /health,/health/live,/health/ready. - Clean shutdown — stopping
flowworkshuts down its embedded Postgres too. If it’s killed ungracefully, Postgres recovers via its write-ahead log on the next start.
Ephemeral sandboxes
Because a machine slot is concurrent, not lifetime, flowwork suits short-lived sandboxes: spin one up, let Claude Code author and run a workflow, then destroy it — the slot frees on teardown. See Licensing, machines & limits for the details.
Next: Configuration reference.