Skip to main content
Open Source
Workflow engine · Apache-2.0

Braidrun's workflow engine and SDK are now open source

Run the Apache-2.0 workflow engine in your own environment, and connect existing applications to the Braidrun cloud platform with 13 official SDK clients. Both paths are open source on GitHub and connect to the same workflow capabilities.

Engine · Apache-2.012 languages · 13 clientsOne runtime and open API
Open-source project

braidrun-workflow: the open workflow runtime

An engine that runs AI workflows defined in YAML, from the command line or from Kotlin code — the same runtime the cloud platform runs behind the scenes.

The open-source repository contains the complete workflow runtime and command-line tool. It runs the steps defined in your YAML in order — agents, code, tool calls and sub-workflows — and isolates them with Docker subprocesses in production.

  • Workflows defined in YAML, runnable from the CLI or Kotlin code
  • Agent steps, code steps, parallelism, conditions, iteration, retries, state machines and sub-workflows
  • Built-in agent presets for coding, research, writing, data analysis, documents, browser automation and more
  • Tool groups for files, shell, Git, HTTP, browser, documents, databases, RAG, email and more
  • Delegate to external coding agents through Claude Code and OpenAI Codex subprocesses
  • Native subprocesses for local development, Docker subprocesses for production isolation
  • Integrates Anthropic, OpenAI, DeepSeek, OpenRouter, Z.ai and NVIDIA models via Koog
  • Can run as an MCP server, exposing tool groups to other clients
terminalbash
# Build the command-line tool
./gradlew installDist

# Validate and run the example bundled in the examples directory
./build/install/braidrun-workflow/bin/braidrun-workflow run \
  examples/workflows/research-summary.yaml
research-summary.yamlyaml
name: research-summary
version: 1.0.0
description: Simple LLM-backed workflow using the researcher preset.
agents:
  researcher:
    preset: researcher
    overrides:
      max_iterations: 32
workflow:
  - step: summarize
    agent: researcher
    input: "Explain what Braidrun Workflow is and list three use cases."
Official SDK

braidrun-sdk: Connect to Braidrun in a language you know

Thirteen type-safe clients across 12 languages turn the open platform API into familiar methods, models, and error types for your stack.

Use the SDK from an existing application to call the Braidrun cloud platform: start workflows, check execution results, read artifacts, handle human approvals, and integrate webhooks. All clients are generated from the same OpenAPI specification, keeping their interfaces and data models aligned.

  • Find workflows and start executions asynchronously
  • Read execution status, final results, and artifacts, and cancel active executions
  • Review, approve, or reject human approvals, and manage and trigger webhooks
  • Typed APIs and data models with support for Bearer, X-API-Key, and permission scopes
  • Every language directory includes installation, configuration, endpoint, and model documentation
CLIENT INDEXAPI version 1.0
12languages
13clients
C#DartGoJavaJavaScriptKotlinPHPPythonRubyRustSwift 5TypeScript FetchTypeScript Axios
WORKFLOWSEXECUTIONSARTIFACTSAPPROVALSWEBHOOKS
Two ways to use it

As a command-line tool, or embedded in your own project

The same parser and executor: run it directly in the terminal, or depend on it as a Kotlin/JVM library.

ShellRun standalone from the CLI

After building, you get a braidrun-workflow command that validates, dry-runs and executes workflows — and can run a single preset agent without a workflow file. Ideal for scripting and automation pipelines.

bash
braidrun-workflow agent \
  --preset researcher \
  --prompt "Summarize this repository and list three use cases"
  • run / validate / dry-run cover execution and checking
  • list-presets and list-tools show the built-in capabilities
  • mcp-server exposes tool groups as an MCP server
LIBIntegrate As A Library

Released versions are distributed through JitPack. One dependency line lets you call WorkflowParser and WorkflowExecutor in your own JVM application — the exact same implementation the CLI uses.

build.gradle.ktskotlin
repositories {
    mavenCentral()
    maven("https://jitpack.io")
}

dependencies {
    implementation("com.github.Braidrun:braidrun-workflow:1.0.5")
}
  • WorkflowParser and WorkflowExecutor are ready to use
  • Native subprocesses for development, Docker subprocesses for production
  • Requires JDK 21 or newer; Docker isolation mode needs Docker
How to choose

The open-source edition gives you the engine; the cloud platform gives you the whole workbench

Both sides share the same runtime. Row by row, here's what the open-source edition includes and what the cloud platform adds on top.

CapabilityOpen-Source Editionbraidrun-workflowCloud Platformbraidrun.com
Workflow Runtime Engine (YAML)
Deploy and run it yourself
Same engine, hosted for you
CLI And Library Integration
CLI plus Kotlin/JVM library
Connect through the official SDKs or REST API
Visual Editor (Canvas ⇄ YAML)
No UI — edit YAML
Canvas and YAML stay in sync both ways
Conversational AI assistant for building workflows
Not provided
Generate and edit workflows by chatting
Breakpoint debugging and failed-step reruns
Debug it yourself
Change values at a breakpoint and resume; completed steps aren't billed again
Auto-Resume After Service Restart
Implement it yourself
Auto-recovers after verifying the definition hash
Run History And Monitoring
Build your own logging
Execution history, cost accounting and alerts
Templates & Modules
A few examples bundled in the repo
240+ templates, 120+ modules and a marketplace
Human Approval Gates
Supported at runtime; notifications are your own
In-app / email / API notifications
Schedule / Webhook / API Triggers
Schedule it yourself
Built-in triggers and chained scheduling
Team Collaboration And Permissions
Not provided
Teams, roles and sharing
Sandboxing And Secret Management
Docker isolation, managed by you
Hosted sandbox plus secret encryption
Technical Support
Community only, no official support
Professional Technical Support
Self-Hosted Deployment
Self-hosted by definition
Private deployment on the Enterprise plan
Native supportPossible, but you build it yourselfNot part of the open-source scope
Why use the cloud platform

If you'd rather manage less infrastructure and build more workflows

The open-source edition hands you the engine to run yourself; the cloud platform adds the interface, collaboration, hosting and support, so workflows ship faster and are easier to maintain.

01Cloud that works out of the boxNo JDK to install, Docker to configure or model keys to manage — sign up and go. We handle the runtime environment, scaling and upgrades.
02Full Visual ControlCanvas and YAML sync both ways; breakpoint debugging, failed-step reruns, run history and cost accounting all live in one interface.
03More Templates And Modules240+ ready-made templates and 120+ functional modules, plus an installable marketplace ecosystem, save you a lot of boilerplate.
04Team CollaborationShare workflows and execution history across your team, assign permissions by role, and route critical actions through human approval before they run.
05Professional Technical SupportThe open-source project offers no technical support; the cloud platform has staff who respond, and the Enterprise plan can agree service levels and private deployment.
06Security & ComplianceHosted sandbox execution, secret encryption and GDPR compliance; the Enterprise plan supports private deployment and audit logs.
An honest take

When the open-source edition is all you need

We don't think everyone should move to the cloud. In the three cases below, the open-source edition is the right choice on its own.

Embed the engine in your own appYou're a developer who wants to call the workflow runtime inside your own JVM application. The parser and executor the library exposes are identical to the CLI's — just depend on the JitPack artifact.Use the open-source library ↗
Run only from the CLI or CIYou don't need an interface, history or collaboration — just to execute workflows in a terminal or pipeline. A single braidrun-workflow run is enough, and it's a natural fit for scripting.Use the CLI ↗
Want full control of the runtime environmentYou want to manage JDK, Docker and model keys yourself, keep data local, and don't need official support. The open-source edition is self-hosted by nature.Self-host it ↗
FAQ

About the engine, SDK, and cloud platform

Are the open-source edition and the cloud platform the same engine?

Yes. The cloud platform is built on the same open-source runtime, adding visual editing, collaboration, run history, monitoring and hosted execution. YAML you get working in the open-source edition can move to the cloud almost unchanged.

What license does braidrun-workflow use? Can I use it commercially?

It's under the Apache-2.0 license, which permits commercial use and modification as long as you keep the license and copyright notices. See the LICENSE file in the repository.

What is the difference between the SDK and the open-source workflow engine?

The SDK lets your application call the Braidrun cloud platform API and is designed for multilingual system integration. braidrun-workflow is a workflow engine and command-line tool that runs locally or on your own servers.

Can I install the SDK directly from each language's package manager?

The SDK is currently distributed through its GitHub source repository, and availability in language-specific package managers may vary. Choose a client and follow the installation instructions in that directory's README.

Does the open-source edition come with technical support?

The open-source project provides no official technical support and relies on the community and documentation. If you need staffed responses and a service-level commitment, use the cloud platform or the Enterprise plan.

Can I start with the open-source edition and migrate to the cloud platform later?

Yes. Many teams validate a workflow from the command line first, then move it to the cloud platform for the visual interface, collaboration and hosting. Workflows are defined in standard YAML, so migration costs little.

Does using the cloud platform lock me in?

The core engine is open source and workflows are defined in standard YAML. You can export a workflow and run it yourself in the open-source edition at any time — there's no lock-in.

Start open source, move to the cloud when you need to
Clone the open-source runtime to run it yourself, connect existing applications with the official SDKs, or sign up for the cloud platform and start building visually.