CO

Conductor OSS

Microservices and workflow orchestration engine

Automation & Workflows ★ 32.2k stars Hard setup Apache-2.0

Conductor is a platform created to orchestrate microservices and business processes at scale. It lets teams define workflows as JSON and run them across distributed task workers.

Key features

  • JSON-defined workflows
  • Distributed task workers
  • Visual workflow editor
  • Built for microservice orchestration

Pros & cons

Strengths

  • Battle-tested at scale
  • Language-agnostic workers

Trade-offs

  • Java stack is resource heavy

Conductor OSS replaces

Last reviewed Aug 26, 2026 · 808 words

Conductor OSS is the wrong tool for 9 out of 10 people who find it while searching for "self-hosted automation". It does not have triggers for your smart home, it does not ship with 400 SaaS integrations, and it needs about 2 GB of RAM before it does anything. What it does is orchestrate long-running, multi-step business processes across services written in different languages, with retries, timeouts and a full execution history, at a scale where Netflix trusted it for years. If that sentence describes your problem, nothing else in the automation category does it as well. If it doesn't, n8n will make you happier by lunchtime.

What "orchestration" means here, and why it isn't n8n

The mental model is a state machine you define in JSON. A workflow is a list of tasks: SIMPLE tasks that a worker process picks up, plus system tasks the server runs itself, such as HTTP, SWITCH, FORK_JOIN, DO_WHILE, WAIT and SUB_WORKFLOW. Workers poll the server over HTTP for tasks of their type, do the work, and post the result back. The server persists every state transition, so a workflow that takes 3 days because step 4 waits on a human approval is normal, and a crash halfway through resumes rather than restarts.

n8n, by contrast, executes a node graph inside one process, fast and visual, and treats a 3-day wait as an edge case. Conductor treats the 3-day wait as the whole point. The visual editor Conductor ships is a viewer and debugger for that JSON, not the primary authoring surface.

The stack you are actually running

The 2 GB minimum in the catalogue is honest and, for a busy instance, generous in the wrong direction. Conductor is a Java server backed by a persistence store (Redis or Postgres) and, optionally, Elasticsearch or OpenSearch for indexing workflow search. Plan on 3 containers minimum:

services:
  conductor-server:
    image: conductoross/conductor:latest
    ports:
      - "8080:8080"   # REST API and Swagger
      - "5000:5000"   # UI
    environment:
      - CONFIG_PROP=config-redis.properties
    depends_on:
      - redis
  redis:
    image: redis:7-alpine

The repository's docker/ directory carries the maintained compose files with Postgres and Elasticsearch variants; use those rather than my sketch when you go past experimenting. The JVM will take whatever heap you allow it, so set JAVA_OPTS=-Xmx1g explicitly or it will claim half the box.

The Netflix history matters for one practical reason

Netflix open-sourced Conductor in 2016 and archived their repository at the end of 2023. The conductor-oss organisation, with Orkes as the main commercial steward, is where development continued, and the 32,128 stars on the catalogue entry belong to that fork. The practical consequence: search results and Stack Overflow answers from the Netflix era still work for workflow definitions, but Docker image names, Maven coordinates and some configuration property names changed. When a tutorial references netflixoss/conductor, expect to translate.

Workers in any language is the real selling point

Because workers only speak HTTP, you can write them in whatever the task suits. The project maintains SDKs for Java, Python, Go, C#, JavaScript and Clojure. A Python worker is around 20 lines: subscribe to a task type, implement a function that takes the input dict and returns an output dict, run the poller. This is the feature that beats Camunda for polyglot teams and beats AWS Step Functions for anyone who doesn't want to be billed per state transition. It is also why "self-hosted" here means running a thing your own services integrate with, not a thing that integrates with your services.

Where it fits against the alternatives

You needPick
Glue between SaaS apps, webhooks, a cron with a UIn8n
Durable code-first workflows with the logic in your languageTemporal
Scripts and jobs with a UI, Postgres-nativeWindmill
JSON-defined microservice orchestration, polyglot workers, audit trailConductor OSS

Temporal is the closest rival and the harder call. Temporal keeps workflow logic in code with replay-based durability, which developers tend to prefer; Conductor keeps it in JSON definitions the server owns, which operations teams tend to prefer because a workflow can be versioned and changed without a deploy. Both are heavy. Neither is a homelab tool.

What I'd do

If I ran a small engineering team with 3 or more services that needed to coordinate multi-step processes, I'd stand up Conductor OSS with Postgres persistence, skip Elasticsearch until workflow search became a daily need, cap the JVM at 1 GB, and write the first workers in Python. I'd budget a week to learn the task types properly. For anything else, including every personal automation I run, I'd close the tab and install n8n. Conductor is superb at a job most self-hosters do not have.

Compare Conductor OSS

9 head-to-head comparisons.

Similar automation & workflows apps