English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Русский | Français

!Node.js 26 !Bun 1.4

Open Flow is an open-source workflow automation platform where AI Agents and people build the same Flow. Ask Codex, Claude Code, or another terminal Agent to create, check, run, and publish a typed workflow through oo flow, then inspect and edit that exact Flow visually in the Workbench.

Use typed nodes for structure, keep custom logic as JavaScript, and run the resulting automation on OOMOL Hosted or infrastructure you control. The graph remains understandable, the code remains code, and the deployment remains under your control.

▶ Watch the 1-minute Open Flow demo

[!IMPORTANT]

Open Flow is in beta. Its contracts are versioned, but the product has not reached its first

stable release.

Build Workflows with an AI Agent

oo flow exposes the authoring lifecycle as versioned, machine-readable commands. An Agent that can use a terminal can:

• discover exact Connector Actions and Provider Triggers;
• create and edit typed Nodes, Edges, Code Tasks, and Trigger bindings;
• check a Draft, run it, and inspect the result;
• publish it to Live or open the same Flow in the Workbench when you ask.

Example request: “Build a workflow that reads unread Gmail messages, formats them, and sends

them to Feishu.”

The Agent creates a real Draft in the selected Open Flow deployment, not a disposable local config. The CLI and Workbench use the same Control API, so an AI-authored change appears in the same visual graph and remains editable by both people and Agents.

Install the oo CLI to author Open Flow from Codex, Claude Code, or another terminal Agent.

To use your own Open Flow, set OO_OPEN_FLOW_URL and OO_OPEN_FLOW_TOKEN in the shell that runs the Agent; see Use Open Flow with OpenConnector and oo CLI.

Choose How to Run Open Flow

Use the same Open Flow product and Workbench through any supported path.

Why Open Flow

• Build with an AI Agent. Use oo flow from Codex, Claude Code, or another terminal Agent to

• Make data dependencies explicit. Every Task declares named, typed inputs and outputs. Each

• Design visually, add code when needed. Compose typed nodes on the canvas, and use Code Tasks

• Run and debug in one place. Validate inputs and the Flow structure before execution, inspect

• Publish long-running automation. Start Flows manually or from Cron schedules, Webhooks,

• Keep operational state together. Flows, immutable Revisions, Publications, Live versions,

• Run untrusted code safely. The Server executes every code Task in a fresh V8 isolate inside a

• Choose where it runs. Use OOMOL Hosted, or run the included Server with Docker on your own

Open Flow is built for workflows that outgrow a no-code prototype but should not become an opaque collection of scripts and infrastructure.

The Graph Is the Runtime Contract

Every Task declares named, typed inputs and outputs. An edge carries a value from a specific output to a specific input, and the runtime starts a node when its inputs are ready.

The graph shows the data dependencies the runtime actually uses: ordinary Flow data cannot be pulled from arbitrary nodes through a hidden runtime store. Independent branches can run concurrently, and canvas position never changes execution behavior.

Typed visual authoring

Detailed view keeps each input, output, type, nullable constraint, and connection explicit on the canvas.

Code where it belongs

Code Tasks place custom JavaScript directly in the graph, with typed inputs and outputs.

How It Works

flowchart LR
  Workbench["Workbench"] -->|"Control API"| Server["Open Flow"]
  CLI["oo flow CLI"] -->|"Control API"| Server
  Server -. "optional" .-> Connector["Connector runtime"]
  Connector --> Providers["Third-party Providers"]
  Server --> Store["SQLite: Flows, Revisions, Publications, Runs"]
  Server --> Triggers["Trigger scheduler: Cron, Webhook, Poll, Integration"]
  Server --> Runtime["Isolated JavaScript runtime"]

The Workbench and CLI only talk to one selected deployment through the versioned Control API. The deployment owns validation, execution, persistence, and Trigger admission. Provider credentials never enter Open Flow: Connector-backed Actions, Provider Triggers, and proxies go through a Connector runtime such as OpenConnector, and Open Flow only stores opaque Connection identities.

Quick Start

You need Docker and OpenSSL. Clone the repository, create an operator token, and start the self-hosted Server:

git clone https://github.com/oomol-lab/open-flow.git
cd open-flow
export OPEN_FLOW_TOKEN="$(openssl rand -hex 32)"
docker build --file apps/server/Dockerfile --tag open-flow-server:dev .
docker run --rm \
  --publish 3000:3000 \
  --env OPEN_FLOW_TOKEN="$OPEN_FLOW_TOKEN" \
  --volume open-flow-data:/data/open-flow \
  open-flow-server:dev

Open http://127.0.0.1:3000 and sign in with the value of OPEN_FLOW_TOKEN. The same value works as a Bearer token for machine clients of the Control API. Flows and Run history are persisted in the open-flow-data Docker volume.

To skip the build, pull the prebuilt multi-arch image ghcr.io/oomol-lab/open-flow or start it with the docker-compose.yml at the repository root. Tags (latest and release versions) and upgrade steps are in the Docker image guide.

The Server is useful without external services. Connector-backed Actions, Provider Triggers, and LLM Tasks fail closed until the corresponding host capability is configured; nothing falls back to an undisclosed service.

For production configuration, TLS, health checks, persistence, backup, and resource limits, see the Server deployment guide and the hardening checklist in SECURITY.md.

Deploy to Fly.io

The same image runs on Fly.io. The repository ships a fly.toml that builds apps/server/Dockerfile, keeps one machine running for Cron and Poll Triggers, and persists SQLite on a Fly volume. See docs/server/fly-io/README.md for app creation, volumes, secrets, deployment, custom domains, and scaling limits.

Connect a Connector

To run Actions and Provider Triggers against services such as GitHub, Gmail, Slack, or Notion, point the Server at a Connector runtime. Both a self-hosted OpenConnector and the OOMOL-hosted Connector expose the required runtime API.

OPEN_FLOW_CONNECTOR_ORIGIN=http://open-connector:3000
Optional when the local Connector has runtime authentication disabled.
OPEN_FLOW_CONNECTOR_TOKEN=replace-with-a-scoped-runtime-token
OPEN_FLOW_CONNECTOR_CONSOLE_ORIGIN=https://connector.example.com

The runtime origin is where the Server reaches the Connector; the console origin is where users' browsers open the Connector Console to authorize accounts. Provider Trigger definitions ship with Open Flow and need no registration. See the configuration reference for Integration callback settings and the constraints on each origin.

To start OpenConnector and Open Flow together, create a runtime token, authorize an account, and build a first Flow with oo flow, see Use Open Flow with OpenConnector and oo CLI.

One Product, Portable Deployments

The Workbench and CLI speak a versioned Control API rather than depending on a particular database or cloud runtime. A deployment owns execution and persistence; clients do not create a second local project format or silently switch to another backend.

This repository contains:

• packages/open-flow: the public @oomol-lab/open-flow npm package with

• packages/command: the oo flow command runtime and the immutable Command

• apps/server: the self-hosted Workbench, Control API, SQLite persistence, Trigger

Read the product and architecture boundaries for the durable model, or the Control API reference for the HTTP contract.

Develop From Source

Open Flow uses Bun for the workspace and Node.js for the Server. Use the versions pinned in .bun-version and .node-version.

bun install --frozen-lockfile
bun run dev

Open the development Workbench at http://localhost:5174. Its Control API requests are proxied to the development backend port (OPEN_FLOW_PORT, default 3001; the proxy target is passed to Vite as OPEN_FLOW_DEV_API_ORIGIN). Connector-backed Actions stay unavailable until OPEN_FLOW_CONNECTOR_ORIGIN is configured. The Connector token remains optional.

The first development run creates an operator token at apps/server/.open-flow-dev/operator-token. Later runs reuse it, so restarting the development server does not invalidate the current Workbench session. Set OPEN_FLOW_TOKEN to use an explicit token instead.

Before submitting a change, run:

bun run check
bun run test
bun run build

Add bun run test:package when touching the published package or CLI, and bun run test:docker when Docker is available to verify the release image, isolated runtime, Workbench, graceful shutdown, and SQLite volume recovery. Do not run bun test at the repository root; it bypasses the workspace test scripts. See CONTRIBUTING.md for the full development rules.

Documentation

Start with the documentation index. The most useful references are:

• Product and architecture boundaries
• Control API
• Command Artifact distribution
• Workbench and Designer frontend notes
• Server deployment
• Docker image on GHCR
• Fly.io deployment
• Use Open Flow with OpenConnector and oo CLI
• Contributing
• Code of Conduct
• Security

Related Projects

• OpenConnector: open-source connector gateway that

• oo CLI: local agent toolkit that hosts the oo flow

Contributing

Issues and pull requests are welcome. Read CONTRIBUTING.md for the development setup, repository rules, and checks to run before opening a pull request. Participation in this project is governed by CODE_OF_CONDUCT.md.

Security

Please report vulnerabilities privately through GitHub private vulnerability reporting rather than public issues. SECURITY.md describes the supported versions, the disclosure process, what is in scope, and how to harden a self-hosted deployment.

License

Apache-2.0. Third-party notices for bundled assets are listed in NOTICE.

Contributors

Thanks to everyone who has helped build Open Flow. Want to join them? See CONTRIBUTING.md.