The 4,208-file checkout is a workflow service, not a worker library
Conductor's 4,208 files and roughly 562,443 source lines implement a central state machine for distributed work. A workflow definition names tasks, branches, loops, waits, approvals, retries, and cancellation rules. Workers poll task queues, perform the application-specific work, and report results. The server persists the graph and task state so a process can survive a worker crash or server restart.
That split suits microservices whose steps outlive one request and agent runs that may pause for a person. The 41.2 MB checkout also contains the UI, server modules, persistence choices, system tasks, and documentation. Conductor is excessive for a background job that can live inside one application. Its value appears when operators need to inspect, retry, pause, rerun, or terminate work across several services.
Versioned JSON stays visible while workers remain ordinary code
Conductor v3.32.1 treats JSON as the canonical workflow representation. SDKs can give developers a code interface, but the server ultimately stores and executes the generated JSON. Running executions keep the definition snapshot taken at startup. New definition versions can coexist, and workers can be written in any supported language because they communicate with the server over HTTP or gRPC.
Task delivery is at least once, a detail that decides whether the engine is safe for payments, emails, or database writes. A worker may finish its side effect and fail before reporting completion, after which Conductor can deliver the task again. The documentation tells workers to be idempotent. Durable state handles orchestration recovery; it cannot make an arbitrary external action safe to repeat.
What happened when we ran it
Our sandbox installed the detected dependency path in 28 seconds, adding 60 packages and occupying 150 MB. The build then succeeded in 7 seconds. We cloned commit 30a103f into an unprivileged Debian container with 3 CPUs and 8 GB of RAM. Pip-audit reported 0 known vulnerabilities in the installed Python packages.
The harness found no test script or target, so tests were skipped. Its repository scan counted 15 CI workflow files, no Dockerfile, and no tests directory. The checkout had 4,208 files, about 562,443 source lines, and used 41.2 MB. These measurements describe the detected Python path and repository signals; they do not establish Java server tests, UI tests, workflow recovery, or runtime throughput.
The 28-second install leaves production persistence untested
The source guide starts the server with in-memory persistence, and it warns that all data disappears when the process stops. The README's short route uses a globally installed CLI, while a published container image bundles the UI and server. Our 28-second install did not start either route, open a port, register a workflow, or interrupt one to verify recovery.
Production has more moving parts than the quick start. Conductor separates the database, task queue, search index, and distributed lock, and its deployment guide marks locking as required for multiple server instances. The README lists 5 persistence backends and 6 message brokers. Database passwords, service addresses, configuration files, and any LLM or MCP credentials belong in the operator's deployment, outside recorded workflow input.
MySQL search and Redis Sentinel expose backend-specific costs
Among 164 open issues, issue 1602 reports a sharp MySQL limitation: with indexing disabled and no Elasticsearch or OpenSearch, fetching a workflow by ID works while search returns an empty result with HTTP 200. The report says PostgreSQL has a native index path while MySQL does not. Teams choosing MySQL must budget another search service if the UI and search API matter.
Issue 1577 describes a different deployment trap. A Redis Sentinel setup with a protected master and sentinels that do not require a password can fail during startup because the client sends the master's credential to the sentinels. The reporter gives a configuration workaround that changes the sentinel security setup. If that topology matches yours, reproduce the issue before moving durable workloads into Conductor.
MCP tasks need allowlists before durable execution
Conductor v3.32.1 includes LLM tasks, MCP tool discovery and calls, dynamic forks, and human tasks. The README also links a separate Conductor Skills project for Claude Code and other coding assistants. These pieces make agent actions visible in the same execution graph as ordinary service work. They also make a poor model decision durable unless the workflow checks it before a tool runs.
The agent guide tells operators to validate generated plans, allow only named tools, cap loops and fan-out, keep credentials out of workflow inputs, and place a human task before consequential writes. Open issue 1599 adds a current reason to test that boundary: its report says LLM_CHAT_COMPLETE output-schema validation uses the input schema and fails unless both are set alike. Schema-dependent agents need that workaround or a verified fix.
164 issues and 92 pull requests show active maintenance
GitHub listed 164 open issues and 92 open pull requests on 2026-09-05, matching the repository API's combined count of 256. The last push was 2026-09-04. Release v3.32.1 arrived on 2026-08-12 with persistence, UI, and agent-related fixes. Those dates and the open work show active development rather than a project resting on its Netflix origin.
Activity does not erase operational risk. The current issue list includes backend search behavior, Redis startup, UI version selection, and LLM schema handling. Our scan found 15 CI workflow files, yet our own harness skipped tests because it found no test target. A production evaluation should pin v3.32.1, run the relevant server and UI suites, and exercise the exact database, queue, index, and lock combination it will deploy.
Conductor pays off when orchestration deserves its own service
Our run's 60 installed packages and 7-second build make the repository cheap to inspect, but they say little about a durable cluster. Conductor is worth the added service when a team needs persisted graphs, cross-language workers, recovery controls, and governed agent steps in one place. For one queue or scheduled job, the server, persistence, index, locking, and worker fleet demand more attention than the workload deserves.