Deployment guide

Conductor

Overview

Conductor OSS is the community-maintained (conductor-oss/conductor) workflow orchestration engine, originally created at Netflix. It runs and visualises microservice workflows. You define workflows and tasks as JSON, start executions over a REST API, and watch them progress in a bundled React UI.

This SecureAnyCloud image installs Conductor OSS 3.30.2 (the self-contained community "lite" build) on an OpenJDK 21 runtime. It runs as a systemd service bound to loopback behind an nginx reverse proxy on port 80, and stores its state in an embedded SQLite database on a dedicated Azure data disk. A unique admin password is generated on the first boot of every VM.

What you get:

  • Conductor OSS 3.30.2 (the community "lite" build: HTTP REST API, bundled React UI, Swagger UI and /health) running on OpenJDK 21
  • The Conductor UI and REST API published on port 80 via nginx (reverse-proxying the loopback-bound server on 127.0.0.1:8080), protected by HTTP Basic auth, with a static unauthenticated /health endpoint
  • An embedded SQLite store (state, queue and indexing) whose data directory lives on a dedicated Azure data disk at /var/lib/conductor, with no external Redis, PostgreSQL or Elasticsearch dependency
  • A unique admin password generated on first boot and written to a root-only credentials file
  • A seeded sac_sample_workflow definition, so the UI shows workflow content out of the box
  • conductor.service and nginx.service as enabled, active systemd units
  • 24/7 SecureAnyCloud support

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B4ms (4 vCPU / 16 GiB RAM) is a good starting size for the Conductor server and its embedded SQLite store.

Configure the NSG to allow inbound 22/tcp from your management network and 80/tcp for the Conductor UI and API. For public exposure, put TLS in front of Conductor (see Enabling HTTPS).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Conductor by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80).

Review the dedicated data disk on the Disks tab, then select Review + create and Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:conductor-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name conductor \
  --image sac1647283583153:conductor-ubuntu-24-04:default:latest \
  --size Standard_B4ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name conductor --port 80 --priority 1010

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

systemctl is-active conductor.service nginx.service

Both services report active. On first boot, Conductor generates a unique admin password and writes the nginx Basic-auth file before nginx starts.

Step 5 - Retrieve your admin password

First boot generates a unique admin password for your VM and writes it to a root-only file:

sudo cat /root/conductor-credentials.txt

This file contains CONDUCTOR_ADMIN_USER (admin), CONDUCTOR_ADMIN_PASSWORD and the CONDUCTOR_URL for your VM. Store the password somewhere safe, because it grants access to the Conductor UI, REST API and Swagger UI.

Step 6 - Check the health endpoint

nginx serves a static health endpoint that needs no login and does not depend on the application being fully started:

curl -s -o /dev/null -w '%{http_code}\n' http://localhost/health

The endpoint returns 200. Conductor OSS has no built-in authentication, so the server is bound to loopback, and the UI, REST API and Swagger UI all sit behind nginx Basic auth. The static /health endpoint is the only unauthenticated path, and it serves as the liveness probe.

Step 7 - Sign in to the Conductor UI

Browse to http://<vm-public-ip>/. When your browser prompts for HTTP Basic credentials, sign in as admin with the password from Step 5. The Conductor UI loads with the Executions, Workflow Definitions and Task Definitions views.

After you sign in, open Definitions, then Workflow Definitions. The image ships a seeded sac_sample_workflow definition, so you have workflow content to explore immediately. You can author your own definitions alongside it.

Step 8 - Visualise the workflow diagram

Open the sac_sample_workflow definition to see its task graph rendered as a diagram. The Conductor UI draws the workflow's tasks and transitions, so you can understand the orchestration at a glance.

Step 9 - Browse task definitions

Open Definitions, then Task Definitions, to inspect the registered task definitions. These hold the metadata (retry policy, timeouts, rate limits) that Conductor uses when it schedules each task in a workflow.

Step 9a - Search workflow executions

Open the Executions view to search and inspect workflow runs by status, workflow name or time range, and drill into any execution to see its task-by-task progress.

For programmatic access, the REST API and an interactive Swagger UI (http://<vm-public-ip>/swagger-ui/index.html) are available behind the same Basic-auth credentials.

Step 10 - Verify the admin login from the command line

Confirm that the admin credentials authenticate against the Conductor REST API and that the seeded workflow is present:

PW=$(sudo grep '^CONDUCTOR_ADMIN_PASSWORD=' /root/conductor-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w '%{http_code}\n' -u "admin:${PW}" http://localhost/api/metadata/workflow

The request returns 200 for the correct password. A wrong password, or no credentials, returns 401. The same GET /api/metadata/workflow lists the seeded sac_sample_workflow definition.

Data storage on the dedicated data disk

Conductor's state, queue and search index live in an embedded SQLite database under /var/lib/conductor, which is a dedicated Azure data disk. Your workflow and task definitions and your execution history are stored on the data volume and survive image and instance maintenance.

df -h /var/lib/conductor

The Conductor server binds to loopback only (127.0.0.1:8080). nginx on port 80 is the single public listener, and it reverse-proxies the UI and REST API behind HTTP Basic auth.

Enabling HTTPS

For public exposure, terminate TLS in front of Conductor. Point a DNS record at the VM's public IP, then install a certificate with the Certbot nginx plugin. Conductor is then served over HTTPS.

Certbot prompts interactively for your email address and domain. Consult the Certbot documentation for the exact certbot --nginx invocation for your domain.

Maintenance

  • Service status: run systemctl status conductor.service to check the Conductor server and systemctl status nginx.service to check the reverse proxy.
  • Logs: run journalctl -u conductor.service to read the Conductor server logs.
  • Restart: run sudo systemctl restart conductor.service after configuration changes.
  • Rotate the admin password: edit the nginx Basic-auth file with sudo htpasswd /etc/nginx/.htpasswd admin, then reload nginx with sudo systemctl reload nginx.
  • Backups: snapshot the /var/lib/conductor data disk to back up the SQLite store.
  • OS updates: the image ships with unattended security updates enabled.

Support

SecureAnyCloud publishes this image and provides 24/7 support for it. The image bundles the open-source Conductor OSS distribution (Apache License 2.0, conductor-oss/conductor). It is not affiliated with or endorsed by Netflix or the Conductor OSS project.

Deploy on Azure

Launch Conductor OSS on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure