## Get Involved

Conductor is maintained in the open. Use the links below to contribute code, ask questions, report issues, or review project policies.

Contributing Guide Development workflow, pull requests, and contribution guidelines.
→
GitHub Discussions Ask questions, propose ideas, and share patterns with the community.
→
Security Policy Review the vulnerability reporting policy and security contact path.
→
Slack Community Join the public community chat for support and project discussion.
→

Project resources stay public and versioned in the repository and docs site.

Apache 2.0 Licensed · Originally created at Netflix

# Code breaks. Infrastructure fails.
Your workflows don't.

Ship workflow changes without redeploying workers. Write your code in any language — the engine guarantees durability, not your coding discipline.

Get Started
View on GitHub
Built for change
Independent workflow upgrades Runtime-defined workflows Dynamic forks and tasks Native LLM + MCP Human-in-the-loop Any-language workers Replayable history
Polyglot Execution

## Keep workers in the stacks you already run

Conductor orchestrates across languages and services instead of forcing workflow logic into a single application runtime

Python
conductor-oss/python-sdk
→
Java
conductor-oss/java-sdk
→
TypeScript
conductor-oss/javascript-sdk
→
.NET
conductor-oss/csharp-sdk
→
Go
conductor-oss/go-sdk
→
Ruby
conductor-oss/ruby-sdk
→
Rust
conductor-oss/rust-sdk
→
Quick Start

## Getting Started

Start with the core OSS paths: quickstart, self-hosting, recipes, and releases

Quickstart Guide

Run Conductor locally, register a workflow, and execute it end to end.

Start here →
Self-Hosting

Deploy Conductor OSS with Docker, shared persistence, and production-ready topology.

Deploy OSS →
Cookbook

Reference patterns for microservices, timers, event-driven workflows, and AI orchestration.

Browse recipes →
Releases

Download tagged releases, review changelogs, and track the project release cadence.

View releases →
Four Pillars

## Why Conductor is stronger when systems change in production

The real advantage is not just durability. It is durable orchestration that can evolve independently, adapt at runtime, span any language boundary, and absorb AI-native workflows without forcing a new stack.

Workflow changes should not require worker redeploys

Version, inspect, and change workflow behavior independently of worker implementations. Running executions keep their snapshot while new executions pick up the new path.

See runtime model →
Dynamic plans should run natively at runtime

Generate workflows on demand, branch with dynamic tasks and forks, and choose sub-workflows per execution without adding a code generation or redeploy step.

See dynamic workflows →
AI orchestration should be infrastructure, not example code

LLM tasks, MCP tool discovery and calls, vector workflows, and human approval are first-class engine capabilities on the same durable runtime as service orchestration.

See AI orchestration →
Polyglot systems need one durable control plane

Keep workers in Java, Python, Go, TypeScript, C#, Ruby, Rust, or any service that can call HTTP. Orchestration should not force a single application runtime.

See SDKs and workers →
Production Proof

## Why the model holds under real failure

The mechanics behind independent workflow evolution, runtime orchestration, and long-running execution in production

01 — Durability
State Persists at Every Step
Workflow state, task state, inputs, outputs, retries, and queues are persisted before execution advances, so workers and servers can fail without losing progress.
Failure semantics →
02 — Recovery
Recovery Is an Operator Primitive
Pause, resume, retry, rerun, and restart are normal controls backed by preserved execution history, not custom recovery logic you have to invent later.
Learn recovery model →
03 — Determinism
No Replay-Safe Workflow Coding Trap
Workflow definitions are pure orchestration. Side effects live in workers and system tasks, so determinism comes from the model itself instead of replay-safe application code discipline.
Why JSON-native →
04 — Versioning
Running Workflows Keep Their Snapshot
Each execution carries the workflow definition snapshot taken at start time, so new workflow behavior can ship without destabilizing executions that are already in flight.
Learn versioning model →
Learn

## Project Resources

Core documentation, architecture, recipes, and direct answers to the common durability and comparison questions

Documentation

Architecture, APIs, workflow primitives, operations, and deployment guidance.

Read Docs →
Durable Execution

Read the project contract for persistence, retries, replay, and recovery behavior.

Read architecture →
Cookbook

Use reference recipes for microservices, event-driven patterns, timers, and AI workflows.

Browse cookbook →
Why Conductor

Read the reasoning behind independent workflow upgrades, runtime-defined orchestration, native AI primitives, and polyglot workers.

Read answers →
Community

## Join the Community

Discuss ideas, contribute in public, and track project activity across the open-source community

Community

Join the public Slack community and GitHub Discussions to ask questions and share patterns.

Join Slack
GitHub

Follow the repository, browse issues, review releases, and track active development.

View on GitHub → Star
Contributing

Open pull requests, report issues, and review the project security and contribution policies.

Read contributing guide →