
conductor
Runs workflows written as JSON on a server you host, resuming them after a crash — infrastructure, not a library.
What is conductor?
Conductor runs workflows you write as JSON — a list of tasks wired together by reference name — on a server you host, and it saves the result of every task, so a run that dies resumes at the task it stopped on instead of from the top. The code that does the real work sits outside the engine in workers: ordinary programs that poll the server over HTTP for one type of task and report the result, so any language that can call an HTTP API can host one and nothing in them has to be written a special way. Recent versions pull LLM calls, MCP tool discovery and vector search into the workflow as built-in task types, which makes an agent loop resumable without any framework code. The price is operational: this is a JVM server with a database, a distributed lock and an index behind it, and the open-source build ships no authentication of its own.
What can you do with conductor?
- Describe the workflow as JSON, then start it from anywhere — A definition is a list of tasks, each with a reference name that later tasks read outputs from. A run begins from the REST or gRPC API, from an event arriving on Kafka, NATS, RabbitMQ or SQS, or from the built-in cron scheduler.
- Workers are ordinary programs that poll for work — Your task code sits outside the engine: it polls the server over HTTP for one type of task, does the work, and reports success or failure. The engine never replays it, so clocks, random values and any library you like are fine. Java, Python, Go, JavaScript and C# have settled SDKs; the Ruby and Rust ones are marked incubating.
- A run survives a crash, and can wait weeks for a person — Every task result is persisted, so a restarted server picks up where it stopped. A HUMAN task holds the workflow open until someone marks it complete through the task update API, with no timer or waiting state of your own to keep.
- Branch, loop and fan out with built-in operators — SWITCH picks a path and DO_WHILE repeats a block until a condition says stop. FORK_JOIN runs branches in parallel, FORK_JOIN_DYNAMIC decides how many branches to create while the workflow is already running, and the JOIN that follows collects what they returned.
- Call an LLM, an MCP server or a vector index without writing a worker — LLM_CHAT_COMPLETE reaches Anthropic, OpenAI, Gemini, Bedrock, Ollama and others, LIST_MCP_TOOLS and CALL_MCP_TOOL work against any MCP server over HTTP, and the indexing and search tasks cover Pinecone, pgvector and MongoDB Atlas. Enabling a provider is a server-side job — set its API key as an environment variable and restart — after which a workflow picks between the enabled ones by parameter.
- Replay a finished run, and leave old versions running — The UI shows every task's input, output, timing and retry history, and you can restart a run from the beginning, rerun it from one task, or retry only the step that failed. Definitions are numbered versions, and a run stays on the definition it started with unless you deliberately restart it on the latest.
Before you choose conductor
- Nothing in the open-source server authenticates callers: the REST and gRPC APIs and UI are open to whoever reaches them, so it needs a proxy in front, and role-based access control is part of Orkes' commercial build.
- It is a JVM server you operate rather than a library you import, and the deployment guide's simplest production stack is still one PostgreSQL for storage, queueing and search plus a Redis for the distributed lock.
Star history
17 Aug to 28 Aug · +47
Frequently asked questions
Is conductor free for commercial use?
conductor is released under the Apache-2.0 licence — OSI-approved open source, which permits commercial use.
How can conductor be deployed?
conductor is available as Self-hosted / Managed cloud.
Documentation
Reproduced from the conductor-oss/conductor README, published under Apache-2.0. Read the original ↗
Orchestrating distributed systems means wrestling with failures, retries, and state recovery. Conductor handles all of that so you don’t have to.
Conductor is an open-source, durable workflow engine built at Netflix for orchestrating microservices, AI agents, and durable workflows at internet scale. Trusted in production at Netflix, Tesla, LinkedIn, and J.P. Morgan. Actively maintained by Orkes and a growing community.
Get Running in 60 Seconds
Prerequisites: Node.js v16+ and Java 21+ must be installed.
npm install -g @conductor-oss/conductor-cli
conductor server start
Open http://localhost:8080 — your server is running with the built-in ui-next UI.
Upgrading from a previous version? The CLI caches the server JAR at
~/.conductor-cli/. If you have an older version cached, force a fresh download:conductor server start latest # or delete the cache manually rm ~/.conductor-cli/conductor-server-latest.jar && conductor server start
Run your first workflow:
# Create a workflow that calls an API and parses the response — no workers needed
curl -s https://raw.githubusercontent.com/conductor-oss/conductor/main/docs/quickstart/workflow.json -o workflow.json
conductor workflow create workflow.json
Note: Running this command twice will return an error on the second call — the workflow already exists. This is expected behavior. Use
conductor workflow updateto modify an existing workflow.
conductor workflow start -w hello_workflow --sync
See the Quickstart guide for the full walkthrough, including writing workers and replaying workflows.
Docker Image for Conductor (includes the ui-next UI):
# UI at http://localhost:5000 | API at http://localhost:8080
docker run -p 5000:5000 -p 8080:8080 conductoross/conductor:next
All CLI commands have equivalent cURL/API calls. See the Quickstart for details.
Why Conductor is the workflow engine of choice for developers
| Durable execution | Every step is persisted. Survives crashes, restarts, and network failures with configurable retries and timeouts. |
| Deterministic by design | Orchestration is separated from business logic — determinism is architectural, not developer discipline. Workers run any code; the workflow graph stays deterministic by construction. |
| AI agent orchestration | 14+ native LLM providers, MCP tool calling, function calling, human-in-the-loop approval, and vector databases for RAG. |
| Dynamic at runtime | Dynamic forks, tasks, and sub-workflows resolved at runtime. LLMs generate JSON workflow definitions and Conductor executes them immediately. |
| Full replayability | Restart from the beginning, rerun from any task, or retry just the failed step — on any workflow, at any time. |
| Internet scale | Battle-tested at Netflix, Tesla, LinkedIn, and J.P. Morgan. Scales horizontally to billions of workflow executions. |
| Polyglot workers | Workers in Java, Python, Go, JavaScript, C#, Ruby, or Rust. Workers poll, execute, and report — run them anywhere. |
| Self-hosted, no lock-in | Apache 2.0. 5 persistence backends, 6 message brokers. Runs anywhere Docker or a JVM runs. |
Ship Agents, Not Framework Code
Conductor workers are plain code — any language, any library, any I/O. No determinism constraints, no SDK ritual. The orchestration layer is declarative and machine-readable, so LLMs generate and compose workflows natively. If an agent crashes at iteration 12, it resumes from iteration 12.
An autonomous think-act agent in Conductor: discover tools via MCP, reason with an LLM, call the chosen tool, repeat until done.
{
"name": "autonomous_agent",
"description": "Agent that loops until the task is complete",
"version": 1,
"tasks": [
{
"name": "discover_tools",
"taskReferenceName": "discover",
"type": "LIST_MCP_TOOLS",
"inputParameters": {
"mcpServer": "${workflow.input.mcpServerUrl}"
}
},
{
"name": "agent_loop",
"taskReferenceName": "loop",
"type": "DO_WHILE",
"loopCondition": "if ($.loop['think'].output.result.done == true) { false; } else { true; }",
"loopOver": [
{
"name": "think",
"taskReferenceName": "think",
"type": "LLM_CHAT_COMPLETE",
"inputParameters": {
"llmProvider": "openai",
"model": "gpt-4o-mini",
"messages": [
{
"role": "system",
"message": "You are an autonomous agent. Available tools: ${discover.output.tools}. Previous results: ${loop.output.results}. Respond with JSON: {\"action\": \"tool_name\", \"arguments\": {}, \"done\": false} or {\"answer\": \"final answer\", \"done\": true}."
},
{ "role": "user", "message": "${workflow.input.task}" }
]
}
},
{
"name": "act",
"taskReferenceName": "act",
"type": "SWITCH",
"expression": "$.think.output.result.done ? 'done' : 'call_tool'",
"decisionCases": {
"call_tool": [
{
"name": "execute_tool",
"taskReferenceName": "tool_call",
"type": "CALL_MCP_TOOL",
"inputParameters": {
"mcpServer": "${workflow.input.mcpServerUrl}",
"method": "${think.output.result.action}",
"arguments": "${think.output.result.arguments}"
}
}
]
}
}
]
}
]
}
Every step is durably persisted — no framework, no SDK lock-in. Code-first engines force your code to be deterministic so the framework can replay it. Conductor makes the engine deterministic — so your code doesn’t have to be.
See the Build Your First AI Agent guide for the full walkthrough.
Conductor Skills for AI Coding Assistants
Conductor Skills let AI coding assistants (Claude Code, Gemini CLI, and others) create, manage, and deploy Conductor workflows directly from your terminal.
Claude
# Install Skills for Claude Code
/plugin marketplace add conductor-oss/conductor-skills
/plugin install conductor@conductor-skills
Install for all detected agents
One command to auto-detect every supported agent on your system and install globally where possible. Re-run anytime — it only installs for newly detected agents.
macOS / Linux
curl -sSL https://conductor-oss.github.io/conductor-skills/install.sh | bash -s -- --all
Windows (PowerShell) / (cmd)
# powershell
irm https://conductor-oss.github.io/conductor-skills/install.ps1 -OutFile install.ps1; .\install.ps1 -All
# cmd
powershell -c "irm https://conductor-oss.github.io/conductor-skills/install.ps1 -OutFile install.ps1; .\install.ps1 -All"
SDKs
| Language | Repository | Install |
|---|---|---|
| ☕ Java | conductor-oss/java-sdk | Maven Central |
| 🐍 Python | conductor-oss/python-sdk | pip install conductor-python |
| 🟨 JavaScript | conductor-oss/javascript-sdk | npm install @io-orkes/conductor-javascript |
| 🐹 Go | conductor-oss/go-sdk | go get github.com/conductor-sdk/conductor-go |
| 🟣 C# | conductor-oss/csharp-sdk | dotnet add package conductor-csharp |
| 💎 Ruby | conductor-oss/ruby-sdk | (incubating) |
| 🦀 Rust | conductor-oss/rust-sdk | (incubating) |
Documentation & Community
- Documentation — Architecture, guides, API reference, and cookbook recipes.
- Slack — Community discussions and support.
- Community Forum — Ask questions and share patterns.
| Backend | Configuration |
|---|---|
| Redis + ES7 (default) | config-redis.properties |
| Redis + ES8 | config-redis-es8.properties |
| Redis + OpenSearch | config-redis-os.properties |
| Postgres | config-postgres.properties |
| Postgres + ES7 | config-postgres-es7.properties |
| MySQL + ES7 | config-mysql.properties |
Build From Source
Requirements: Docker Desktop, Java (JDK) 21+, Node.js 18+ and pnpm (for UI)
git clone https://github.com/conductor-oss/conductor
cd conductor
./gradlew build
# (optional) Build UI (ui-next) and embed it in the server
# ./build_ui_next.sh
# Start local server
cd server
../gradlew bootRun
Run the UI in dev mode (hot-reload at http://localhost:1234):
Requires a running Conductor server on http://localhost:8080. Enable corepack once if you haven’t already:
corepack enable
Then start the dev server:
cd ui-next
pnpm install
pnpm dev
Open http://localhost:1234 — the UI reloads automatically on file changes.
See the full build guide for details.
FAQ
Yes. Conductor OSS is the continuation of the original Netflix Conductor repository after Netflix contributed the project to the open-source foundation.
Yes. Conductor is a fully open-source workflow engine licensed under Apache 2.0. You can self-host on your own infrastructure with 5 persistence backends and 6 message brokers.
Yes. Orkes is the primary maintainer and offers an enterprise SaaS platform for Conductor across all major cloud providers.
Yes. Built at Netflix, battle-tested at internet scale. Conductor scales horizontally across multiple server instances to handle billions of workflow executions.
Yes. Conductor pioneered durable execution patterns, ensuring workflows and durable agents complete reliably despite infrastructure failures or crashes. Every step is persisted and recoverable.
Yes. Conductor preserves full execution history indefinitely. You can restart from the beginning, rerun from a specific task, or retry just the failed step — via API or UI.
Yes. Conductor provides native integration with 14+ LLM providers (Anthropic, OpenAI, Gemini, Bedrock, and more), MCP tool calling, function calling, human-in-the-loop approval, and vector database integration for RAG.
Coupling orchestration logic with business logic forces developers to maintain determinism constraints manually — no direct I/O, no system time, no randomness in workflow definitions. Conductor eliminates this entire class of bugs by making the orchestration layer deterministic by construction. Workers are plain code with zero framework constraints — write them in any language, use any library, call any API.
It depends on what you mean by “powerful.” In code-first engines, the workflow definition and your business logic live in the same runtime — which means the engine must replay your code to recover state. That forces determinism constraints on your business logic: no direct I/O, no system time, no threads, no randomness. Conductor separates these concerns. The orchestration graph is declarative (JSON), so it’s deterministic by construction. Your workers are plain code with zero constraints — use any language, any library, call any API. You get the full power of code where it matters (business logic) without the framework tax where it doesn’t (orchestration).
Yes. Conductor supports SWITCH (conditional branching), DO_WHILE (loops with configurable iteration cleanup), FORK_JOIN (parallel execution with dynamic fanout), SUB_WORKFLOW (composition), and DYNAMIC tasks resolved at runtime. These are composable — you can nest loops inside branches inside forks. For error handling, every task supports configurable retries, timeouts, and optional/compensating tasks. The declarative model doesn’t limit complexity — it makes complexity visible and debuggable.
Workflow definitions are versioned by number. Running executions continue on the version they started with — deploying a new version never breaks in-flight workflows. There’s no replay compatibility problem because Conductor doesn’t replay your code. The orchestration graph is the source of truth, and each execution is pinned to its definition version. Update orchestration logic without redeploying workers and without worrying about breaking running workflows.
Conductor provides a built-in visual UI for designing, running, and debugging workflows. Every execution is fully observable: you can inspect the input, output, timing, and retry history of every task. For type safety, Conductor validates workflow inputs and task I/O against JSON Schema. Workers are plain code in your language of choice — you get full IDE support, type checking, and debugging for your business logic. The orchestration layer is visible in the UI, not hidden inside a framework.
Yes. Conductor is designed for long-running workflows. Executions are fully persisted — a workflow can pause for months waiting for a human approval, an external signal, or a scheduled timer, and resume exactly where it left off. There’s no in-memory state to lose. This is the same mechanism that makes AI agent loops durable: if iteration 12 waits for a human review for three weeks, iteration 13 picks up right where it left off.
You gain flexibility. Because workflows are JSON, LLMs can generate and modify them at runtime — no compile/deploy cycle. Dynamic forks let you fan out to a variable number of parallel tasks determined at runtime. Dynamic sub-workflows let one workflow compose others by name. And because workers are decoupled from orchestration, you can update the workflow graph or swap worker implementations independently. Code-first engines couple these together, so changing orchestration means redeploying and re-versioning your code.
Conductor is an open-source workflow engine with native LLM task types for 14+ providers, built-in MCP integration, durable execution, full replayability, and 7 language SDKs. Unlike code-first engines, Conductor separates orchestration from business logic — determinism is an architectural guarantee, not a developer constraint. Your workers are plain code with zero framework rules. The orchestration layer is declarative, so it’s observable, versionable, and composable by LLMs. Battle-tested at Netflix, Tesla, LinkedIn, and J.P. Morgan.
100% compatible. Orkes Conductor is built on top of Conductor OSS with full API and workflow compatibility.
Roadmap
See the Conductor OSS Roadmap. Want to participate? Reach out.