In this post, we interview Alex Poliakov, head of DBOS Solutions Architecture. Alex has been with DBOS since 2023, helping DBOS users get their durable backends up and running. This is the first in a series of interviews with Alex about topics that frequently arise when working with DBOS users. 

Question 1: What is DBOS Conductor?

“To answer that, let me start with some helpful context. If you’re new to DBOS, it’s a system that makes your applications durable or resilient to failure. There are two major components to DBOS. The first is DBOS Transact, an open-source library for building durable workflows. It provides the core durable execution primitives, including workflows and steps, schedules, queues, and workflow communication, with state stored in your Postgres database. If your software fails for any reason, the library retrieves the saved state information on restart and resumes workflow execution exactly where it left off prior to the failure. Unlike other durable execution systems, which force you to separate your workflow code from the rest of your application and run it on dedicated orchestration servers, the DBOS library embeds durability within your application, making it much simpler to adopt and operate. 

DBOS Conductor is the workflow control plane for your DBOS apps. Conductor makes it easier to run DBOS applications in production with auto-scaling and high availability. It also gives you visibility into workflow behavior and history. It is offered as a service hosted by DBOS, and it’s also available for self-hosting wherever you’d like to run it.”

Question 2: What is a Workflow Control Plane?

“As you increase the number and variety of workflows and DBOS Transact applications instances (or ‘workers,’ as we call them), it becomes helpful to have visibility into, and control over, workflow and worker operations. DBOS Conductor gives you that. It connects to your application workers to monitor their health, coordinate workflow recovery across application workers, provide cluster-wide observability and management, integrate with your monitoring and alerting infrastructure, and enforce data retention policies. Your workflows continue to execute inside your workers, while Conductor simplifies the operational visibility and control to keep them running reliably.

Here’s a diagram we use to show how DBOS Conductor, DBOS Transact, Postgres, and your application work together:

So, to summarize, DBOS Conductor provides the following:

• High availability for workflows: Whenever one of your workers fails, Conductor automatically recovers its workflows to another server.
• Workflow and queue management: Interactively cancel, pause, or resume your workflows, or restart (fork) them from a particular step.
• Observability for workflows and queues: From a dashboard, view the timelines of your workflows and contents of your queues.
• Integrations for observability and alerting: Export metrics data to your existing observability infrastructure and configure alerts.
• Retention policies: automatically delete workflow and step data after enough time has passed or after your database reaches a certain size.”

Question 3: Do I need DBOS Conductor to run DBOS in production?

“DBOS Transact contains all the primitives to make your workflows and queues durable. Conductor provides automatic liveness tracking and recovery in applications that use more than one worker. And it comes packed with all the features that production teams tend to need - from observability to auditing, troubleshooting and org management with RBAC, to integrating with platforms like Kubernetes or Datadog. Strictly speaking, you can find ways to run without it. But we recommend Conductor whenever you are running in a production environment.”

Question 4: Does DBOS Conductor store sensitive workflow data?

“No. DBOS Conductor does not store any workflow data or metadata. All of that state is stored only in your Postgres database. It’s also worth noting that Conductor never accesses your Postgres directly. It only communicates with your app workers via a secure web socket. This architecture has useful implications for security and data privacy:

• Conductor doesn’t need inbound access to your application workers or database. Your servers establish outbound web socket connections to Conductor.
• Conductor never stores any of your application data. Any data it needs (for example to display a workflow timeline) it retrieves from your application through the websocket. Thus, while data may transit to Conductor, it is never stored there.
• Metadata-only mode: This is an option if you need stronger privacy guarantees. When enabled, your workflow data (such as workflow or step inputs or outputs) are never accessed by Conductor. Conductor can still access and visualize workflow metadata such as workflow or step IDs. All sensitive information stays between your Postgres and your workers; it is never even sent to Conductor.
• Role-based access control (RBAC): Control what resources each user in your organization can view or manage.
• Self-hosted Conductor: If you need complete privacy, you can also self-host Conductor on your own infrastructure. See the documentation for that here.”

Question 5: How does Conductor simplify high availability?

“Conductor simplifies high availability for your workflows: if any of your application workers fails, Conductor automatically detects the failure and recovers your workflows to another worker. This works because Conductor has a websocket connection to each worker, so it notices immediately if any goes offline. When it detects a worker failure (which could be a pod crash, maintenance, or just a rolling deploy) it waits a configurable grace period, then signals another worker to recover the affected workflows.

Another benefit of the architecture is that Conductor remains off the critical path. If there is a Conductor outage, your workflows continue running durably and uninterrupted. When the connection is restored, Conductor resumes workflow recovery, even for servers that have failed during the outage. Here’s a diagram that illustrates how DBOS Conductor facilitates high availability for durable backends:”

Question 6: What does it offer for observability and management?

“So, by now you know DBOS stores a record of the state of every workflow, workflow step, and queue in Postgres. Observability of this data is really helpful if you need to troubleshoot or optimize workflows, resolve customer issues, meet regulatory reporting requirements, and so on. It’s especially helpful in long-running and human-in-the-loop workflows or in agentic AI scenarios where workflow definitions may be non-deterministic. DBOS Conductor visualizes workflow status and history so you can see if humans in the loop are blocking progress, or unexpected LLM responses are causing troublesome outcomes, etc. You can also manage workflows, cancelling them, resuming them, or even forking them from a specific step. Workflow data is easy to integrate with other observability tools like Datadog, and retention policies are configurable. I’ve shared images below that show some of the insights DBOS Conductor provides into workflow behavior:

Current workflow status:

Workflow timeline drill-down:

Queue status and health:

Workflow observability data sourced by DBOS Conductor, integrated into Grafana:

Learn More

We hope this interview has been helpful. If you’d like to chat with Alex about Conductor or anything else, you can reach him via the DBOS Discord community: https://discord.gg/eMUHrvbu67