When Conductor OSS is enough and when Orkes Conductor earns its place
Conductor OSS is enough when your platform team can run it well itself. The Apache-2.0 server needs Java 21 or later and ships as a Docker image that bundles the server and UI, so the core question is whether your team already operates Java services in production. It is also sufficient when you are willing to own the persistence and message broker choices. The documentation lists 5 persistence backends, including PostgreSQL and Redis, and 6 message brokers, with Elasticsearch or OpenSearch for indexing. Each combination is a decision you make, test and upgrade yourself. Because Netflix stopped maintaining the upstream project on GitHub from December 13, 2023, you should also accept that upgrades, security fixes and their timing come from the conductor-oss project and your own change process.
Orkes Conductor earns its place when operations capacity or vendor support terms are the constraint. Orkes describes its enterprise platform as built on Conductor OSS with full compatibility between the two, and it offers hosted deployments across major cloud providers. That makes it the stronger option if you lack spare Java and data-store operators, if you prefer a hosted deployment, or if you need a named party to answer for production incidents. Before you rely on it, confirm with Orkes in writing which features go beyond the documented compatibility and hosting claims, including any tooling, SDK coverage, upgrade commitments, support hours, data residency and the terms that govern your persistence and broker choices. Ask how migration works in both directions, since that determines how reversible the decision is.
Which capabilities Conductor OSS documents and what to confirm for Orkes
This table sets the capabilities Conductor OSS documents against the questions to put to Orkes in writing. Where Orkes is marked as a question, the vendor has not been confirmed for that row, so treat the answer as open until it arrives in a written quote or product document. Use the table as a checklist for your vendor conversation.
| Capability | Conductor OSS | Orkes Conductor |
|---|---|---|
| License | Apache-2.0 (conductor-oss/conductor repository) | Built on Conductor OSS with full compatibility; confirm license and any proprietary components in writing |
| Persistence backends | 5 documented backends, including PostgreSQL and Redis | Confirm which backends are offered in the hosted and self-managed options |
| Message brokers | 6 documented message brokers | Confirm which brokers are supported and whether the set matches Conductor OSS |
| Indexing with Elasticsearch or OpenSearch | Elasticsearch or OpenSearch supported for indexing | Confirm indexing backend options and version support for each deployment model |
| Official SDKs | Java, Python, JavaScript, Go and C#; Ruby SDK incubating | Confirm SDK coverage and whether Orkes-specific SDK features require a paid tier |
| Server runtime | Requires Java 21 or later | Confirm runtime requirements for any self-managed Orkes component |
| Docker packaging of server and UI | Docker image bundles the server and UI | Confirm whether Orkes ships the same image or a separate packaged distribution |
| Deployment model | Self-hosted in your own infrastructure | Hosted deployments across major cloud providers; confirm which regions, tenancy models and self-managed options are offered |
How persistence and broker choices shape the operating load
The first decision a self-hoster makes with Conductor OSS is which persistence backend and message broker to run, because those two choices set most of the work that follows: backups, upgrades, scaling and on-call. The Conductor documentation states support for five persistence backends, including PostgreSQL and Redis, and six message brokers. Each combination is a different system with its own backup method, failover behavior, upgrade path and failure modes. Before comparing options, confirm the exact backend and broker pair you intend to run against the current Conductor OSS documentation, and record which versions your platform team will need to patch and restore.
Search is a separate concern that many teams underestimate. Conductor uses Elasticsearch or OpenSearch for indexing, so a production deployment includes a third stateful cluster alongside the workflow store and the broker. That cluster needs its own capacity planning, snapshot policy, index lifecycle rules and monitoring, and its outage affects visibility into running workflows even when execution continues. Ask your team which search engine they already operate and at what version before choosing, because running a search cluster you have never supported is one of the larger hidden costs of self-hosting.
If your platform team already runs PostgreSQL and a supported broker, choosing those components reduces the number of new skills your on-call engineers must acquire, and it lets existing backup and patching runbooks cover Conductor. The same persistence, broker and search choices are the first items to confirm with Orkes if a hosted deployment is considered, since they determine what the vendor manages, what stays in your environment and what migration would involve later. Ask Orkes in writing which backends, brokers and index engines its hosted offering supports, and how data would move if you change direction.
What standing up Conductor OSS in your own environment involves
This sequence takes a platform team from a bare host or container platform to a Conductor OSS deployment with persistence, brokers, indexing, workers, access controls and tested backups and upgrades. Each step names what drives its effort so you can size the work against your own skills and infrastructure before asking for a quote.
Confirm the Java 21 runtime and packaging choice
The platform team confirms that the server host can run Java 21 or later, or decides to run the Docker image, which bundles the server and the UI in one package. Choosing between a bare JVM install and the container depends mostly on whether your organization already operates container platforms and has a patching process for them. The step is done when the team has a documented runtime version, a chosen packaging method, and a test instance that starts and serves the UI. Confirm the exact supported JDK and image tags in the Conductor OSS documentation before pinning them.
Select and provision the persistence backend
The platform team chooses one of the persistence backends that the Conductor documentation lists, including PostgreSQL and Redis, and provisions it with backup, high availability and monitoring in line with existing database standards. Effort is driven mostly by existing database skills and the operating model already in place, and by expected workflow volume and retention, which determine storage sizing. The step is done when the server connects to the chosen store, a sample workflow run is persisted, and the team has restore steps that have been exercised at least once. Ask your vendor or DeployOpen to confirm which backend combinations are currently supported.
Select and provision the message broker
The team selects one of the six message brokers that the Conductor documentation describes and deploys it with clustering, authentication and monitoring that match internal standards. The main drivers are the throughput the broker must sustain, which follows from task volume, and whether the organization already runs and supports that broker. The step is done when task queues are created, a test task round trip completes through the broker, and broker failure behavior has been observed in a non-production environment. Confirm the broker's support status and compatibility with your chosen persistence backend in the Conductor documentation.
Provision Elasticsearch or OpenSearch for indexing
The team provisions Elasticsearch or OpenSearch for workflow indexing, sized for the search and retention needs of operators who use the UI and API to find executions. Effort depends on existing search cluster operations, the number of workflow executions retained, and how long operators need to query history. The step is done when the server writes indexes for test executions, search results return in the UI, and index retention and rollover settings are documented. Confirm the supported versions for your Conductor release before choosing a cluster version.
Deploy workers in the chosen SDK language
Application teams write workers in the language they already operate, using one of the official SDKs for Java, Python, JavaScript, Go or C#, or the incubating Ruby SDK if that fits their stack. Workers hold the business logic, while Conductor holds the workflow definitions in JSON, so the effort sits mainly with the application teams and their existing deployment pipelines. The step is done when a worker registers with the server, polls a task, reports a result, and a workflow definition that calls it completes end to end in a test environment. Confirm SDK version compatibility with your server release before pinning dependencies.
Configure authentication and network access
The team decides how operators, application teams and workers authenticate to the server and UI, and restricts network paths so only approved clients reach the API, the broker and the stores. Effort is driven by the identity provider already in use, the existing network segmentation model, and whether workers run in the same network zone as the server. The step is done when access tests confirm that unauthorized clients are refused, that approved workers and operators can connect, and that the decisions are recorded in a configuration baseline. Confirm which authentication options your Conductor release supports, since the open-source server may differ from hosted offerings.
Set up backups and upgrade testing
The team schedules backups for the persistence store and the search index, tests restores into a separate environment, and defines a procedure for applying new Conductor releases to a staging copy before production. Ongoing effort recurs with every release and is shaped by how often the organization upgrades, how much workflow history must be kept, and how many services depend on the platform. The step is done when a restore has been proven, a staging upgrade has been rehearsed with a rollback plan, and an owner is named for release tracking against the Conductor releases page. Scope, deliverables and timelines for an implementation of this sequence are agreed in writing before work starts, which is how DeployOpen scopes such work.
What the Apache-2.0 license covers and what Orkes agreements add
The Apache-2.0 license governs what you may do with Conductor OSS code, but it does not decide who maintains it, who answers your tickets or who carries upgrade work. Those questions are set by Netflix's maintenance decision, the community model and any written agreement with Orkes.
Conductor OSS license terms
The conductor-oss/conductor repository is licensed under Apache-2.0, which allows you to use, modify and self-host the code without paying a license fee to the project. Confirm with your legal team that the license terms fit your internal distribution, any forks you plan to maintain and how you track third-party dependencies in your build. The license covers the code only, not the support you receive for it.
Netflix ended OSS maintenance
Netflix discontinued maintenance of Conductor OSS on GitHub effective December 13, 2023, and archived the Netflix/conductor repository in favor of its internal fork. Treat the conductor-oss repository as the open-source line, maintained by Orkes and the community. Any Netflix-era fix or design choice you read about may not appear in the public line, so check the release notes before assuming a feature exists.
Orkes commercial terms and tiers
Orkes Conductor is the enterprise platform built on Conductor OSS, with full compatibility between the two and hosted deployments across major cloud providers. The published facts do not list Orkes's license terms, support tiers, response times or price, so ask Orkes for these in writing and compare them against the scope you need. Confirm which parts of the platform are covered by the agreement and whether the compatibility guarantee is stated in the contract.
Community support versus contracted support
Community support for the OSS line runs through the repository issues, the project documentation and the wider user base, with no response time promised by anyone. A contracted agreement adds a named commitment, usually defined in an SLA. Ask Orkes what severity levels, hours and escalation paths its agreements include, and decide in advance which production incidents you cannot handle without a contractual path.
Who owns OSS upgrades
With self-hosted Conductor OSS, your team plans and tests each upgrade, including the Java 21 runtime and the persistence and broker versions you run. The latest documented tag is v3.32.5, published September 25, 2026. A hosted or contracted option can move parts of that work to Orkes under its agreement, so ask which upgrades, rollbacks and compatibility tests are included and who signs off on them.
How hosted deployment and vendor support change who runs Conductor
The main operational split between Conductor OSS and Orkes Conductor is who runs the server, its persistence and broker layers, and the upgrade path. With Conductor OSS, your team or a partner runs the Java 21 server, the UI bundled in the Docker image, and the chosen persistence backend in your own cloud account, data center or air-gapped network. With Orkes hosted deployments across major cloud providers, Orkes operates the platform on infrastructure it provides, and your team keeps a different set of duties. Confirm with Orkes which infrastructure region, tenancy and data-processing terms apply before you assume any hosted option fits your residency requirements, since the Conductor documentation supplied for this topic does not describe those details.
Some responsibilities stay with you in either model. Data residency decisions, identity integration with your single sign-on and role model, network policy between workers and the Conductor API, and secrets handling for worker credentials remain yours to design and evidence. Workflow design is also yours: the JSON workflow definitions, their versions, and the worker code in your chosen language are business logic your engineers own, whether the server is self-hosted or hosted. A support contract or hosted service changes who patches the server, who responds to incidents at the platform layer, and who performs upgrades, but it does not transfer ownership of the workflows or the data your workers process. Ask Orkes in writing which of these items the service covers and which remain on your side of the responsibility line.
DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and it offers ongoing support, upgrades and continuous testing as retainers. That work applies to a self-hosted Conductor OSS deployment. The vendor's hosted Orkes service is a separate decision, made with Orkes and governed by its own terms, and DeployOpen is not a reseller or partner of Orkes. A useful test for your team is to list every operational task in a six-month plan, such as backup restore tests, server upgrades across Conductor releases, persistence maintenance and on-call escalation, then assign each one to your staff, a DeployOpen retainer, or the vendor. The gaps in that list are where cost and risk accumulate.
What each path costs to own and what to ask for in a quote
This table sets out who pays for each cost component on the Conductor OSS and Orkes Conductor paths, which costs recur, and what to request in writing. DeployOpen publishes no price list, so a quote follows the written scope, and the table is most useful as a checklist for comparing quotes and vendor terms side by side.
| Cost component | Conductor OSS self-hosted | Orkes Conductor |
|---|---|---|
| Software license | None for the Apache-2.0 licensed server and UI. Confirm the license of any add-on you adopt. | Enterprise terms apply. Confirm fees, scope and renewal terms with Orkes in writing. |
| Infrastructure | Your cloud account or data center pays for compute, persistence, message broker, and search index (Elasticsearch or OpenSearch). Size each against your expected load. | Confirm with Orkes whether hosted deployments include these components, which cloud provider and region apply, and which costs stay on your account. |
| Implementation effort | Scoped in writing with DeployOpen or delivered in-house. Covers workflow design, worker code, persistence choice, and integration with identity and logging. | Confirm with Orkes and your integrator what onboarding, migration and workflow design work is included, and what you still deliver. |
| Upgrades and patching | In-house team, or a DeployOpen retainer covering upgrades, testing and documentation. Track Conductor releases such as v3.32.5 and plan the rollout. | Governed by the Orkes agreement. Confirm who applies upgrades, the notice period, and whether downtime or maintenance windows are included. |
| Support | Community support through the project. Any paid support comes from a separate contract you arrange. | Contracted support from Orkes. Confirm response targets, severity definitions, and any SLA language in the agreement. |
| Exit and migration | Low license exit cost since you control the code and data. Ask what backups and data export procedures you will maintain. | Confirm data export formats, workflow definition portability, and the notice and assistance terms if you leave the hosted service. |
Moving from self-hosted Conductor OSS to Orkes Conductor, or back
This sequence shows how a team moves running Conductor workloads between self-hosted Conductor OSS and Orkes Conductor without losing workflow definitions, worker behavior or in-flight executions. Each step ends with a written check, so the move can be paused or reversed at a known point.
Inventory definitions, workers and dependencies
List every workflow definition, stored as JSON, along with its version, the workers that execute its tasks, and the SDK and language versions those workers use. Record the persistence backend, the message broker, and the search index (Elasticsearch or OpenSearch) the current server depends on, plus the Java version on each server. The output is a single inventory that names each definition, worker and dependency, reviewed by the platform owner and the workflow owners. Confirm with your team that the inventory matches what is actually deployed, not only what the repository says.
Confirm compatibility scope with Orkes
Ask Orkes in writing to document exactly which features, SDK versions, API behaviors and integrations are covered by the full compatibility the vendor describes with Conductor OSS. Ask specifically about any gap you found in the inventory, such as a custom task type, a broker or persistence option, or a worker library pinned to an older SDK. Request the list of known differences and how each is handled. The check is a signed or dated written answer that you can map against your inventory, with every gap either resolved or accepted by the owner.
Rehearse the move on a copy of workflow data
Restore a copy of the production workflow metadata and a representative sample of execution history into a non-production Orkes environment, then run the inventoried definitions through it with the same worker code. Compare outputs, task ordering, retry behavior, and the visibility of past executions against the source system. Illustratively, if a definition that retries a payment task produces a different retry count, that difference goes into the gap list before any cutover. The rehearsal is complete when every definition has a recorded pass or a documented exception.
Agree cutover timing and in-flight handling
Before any production work begins, agree in writing the cutover window, the expected data volume to be moved, and how running workflows will be handled: drain and wait for completion, migrate in place, or restart from a checkpoint your team defines. Confirm who performs each action, who approves the cutover, and how the team will be notified. Timing, data volume and in-flight handling should come from the signed scope and vendor confirmation, not from assumptions in this guide. The output is an approved runbook that names each owner.
Cut over workers and running workflows
Point workers at the target environment in controlled groups, starting with the least critical definitions, and confirm each group polls and completes tasks before moving the next. Hold new workflow starts on the source system while in-flight executions drain or are migrated according to the agreed plan. Monitor task failures, queue depth and execution status against the rehearsal baseline. The step is done when the source system has no active executions it owns and the target shows the same definitions and completion results as the rehearsal.
Keep a tested rollback path
Before cutover, write the rollback steps: which workers switch back, how new starts return to the source, how executions that began on the target are handled, and who decides to roll back. Keep the source deployment, its persistence backend and its broker running and backed up until the agreed stability period ends. Rehearse the rollback once in non-production so the steps are proven rather than assumed. The check is a rollback test record and a signed decision to retire the source only after the window closes.
Document the return path to self-hosting
Record the procedure for moving back to self-hosted Conductor OSS in the same level of detail as the forward move, including the server version, the Java 21 or later requirement, the Docker image or deployment method, and the persistence, broker and indexing components you would need to stand up. Note which Orkes-specific features would need replacing, and which definitions and worker code would carry over unchanged. Store this runbook with the inventory so it stays current. The output is a reviewed document that the platform team can execute without the original migration authors.
What buyers ask before choosing Conductor OSS or Orkes Conductor
Is Conductor OSS still maintained after Netflix ended its maintenance?
Yes, the open-source project continues under the Apache-2.0 license, maintained by Orkes and the community. Netflix discontinued maintenance of Conductor OSS on GitHub effective December 13, 2023, and archived its repository in favor of an internal fork. The active project is the conductor-oss/conductor repository, which published Conductor v3.32.5 on September 25, 2026. Before you commit, review the release history and open issues yourself, check how frequently your required fixes land, and decide whether your team will track upgrades on its own schedule.
Can a small team run Conductor OSS without outside help?
A small team can run it, but the work is operational more than a single installation step. The server requires Java 21 or later, and the Docker image bundles the server and UI, which helps with first deployment. The harder parts are choosing a persistence backend from the supported options, operating a message broker, configuring indexing with Elasticsearch or OpenSearch, and testing every upgrade against your own workflows. Ask yourself whether you have engineers who already run Java services, these data stores and broker clusters, and whether they can spare time for upgrade testing and on-call support. If any of those answers is no, plan for outside help.
What does the Orkes enterprise edition add over Conductor OSS?
The documented facts establish two points: Orkes Conductor is built on Conductor OSS with full compatibility between the two, and Orkes offers hosted deployments across major cloud providers. Beyond that, the enterprise feature list, support terms and licensing conditions are for Orkes to state. Ask Orkes for a written list of paid features, the support tiers included, the hosting regions available, and the exact terms for running it in your own cloud account. Compare that list against the specific operational gaps you expect to face, such as access control, monitoring or upgrade management, rather than against a general sense of enterprise value.
What does an implementation partner do that the free edition does not?
The Apache-2.0 software is free to use, but the work around it is not. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Conductor OSS, that can cover scoping the workflows to migrate, choosing and configuring the persistence and broker stack, setting up backups and upgrade testing, writing runbooks, and providing support through a retainer. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope.
How long does a migration to Conductor take?
No duration can be stated from the documented facts, because the answer depends on the number of workflows, the volume of data in flight and in history, the worker code that must change, and the cutover rules you accept. Migration work is usually easiest to estimate when you inventory workflow definitions, classify running executions as drain, migrate or restart, and agree how long old and new systems run in parallel. Ask any implementation partner, including DeployOpen, to base the timeline on that inventory. A quote follows from the written scope, and the timeline should appear in the same document.
Can we switch between Conductor OSS and Orkes Conductor later?
In principle yes, because the documented facts describe Orkes Conductor as fully compatible with Conductor OSS. That compatibility is the reason the move is expected to involve configuration and operations work rather than rewriting workflows. Confirm the specifics with Orkes before relying on it: the supported versions on each side, whether workflow definitions and execution history move without transformation, how persistence and broker settings map across, and what happens to any custom extensions or worker code. Write the answers into your contract so the exit path is documented before you need it.
Which SDK should we use for Conductor workers?
Choose the SDK that matches the language your workers already use, because the business logic lives in workers and workflows are JSON graphs that any SDK can drive. Conductor provides official SDKs for Java, Python, JavaScript, Go and C#. A Ruby SDK is incubating, so confirm its maturity before standardizing on it. Check each SDK's version compatibility with the server version you plan to run, and test worker retries and timeouts against your own failure cases before rollout.
How DeployOpen scopes, delivers and supports Conductor OSS and Orkes deployments
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Conductor OSS or an Orkes Conductor deployment, we start from the written scope and the constraints of your environment, then deliver a system your team can run.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope should name the persistence and broker choices, the search index and the SDK languages your workers use.
- Ask for the scope to state whether Orkes Conductor, a hosted deployment or Conductor OSS in your own cloud account is assumed.
How we build
- We deploy the server, UI and supporting services into your cloud accounts, data centers or air-gapped network.
- We integrate workflow definitions, workers and identity, and configure the persistence and message broker agreed in scope.
- Security testing of the APIs and infrastructure can be included in scope before the system goes live.
How we hand over
- Deliverables include configuration, runbooks, backup and upgrade procedures and architecture documentation written for your team.
- We document how workflow versions, workers and infrastructure are promoted between environments.
- Handover sessions cover operating the system, so your engineers can run workflows without depending on us for routine changes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Support scope should be agreed in writing, including who handles Conductor version upgrades and dependency patches.
- Ask us to confirm response expectations in the retainer, since we do not publish fixed service levels here.
