Conductor OSS on Ubuntu 24.04 on Azure User Guide

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. The cloudimg image installs Conductor OSS 3.30.2 (the self-contained community "lite" build) on an OpenJDK 21 runtime, runs it as a systemd service bound to loopback behind an nginx reverse proxy on port 80, stores its state in an embedded SQLite database on a dedicated Azure data disk, and generates a unique admin password on the first boot of every VM. Backed by 24/7 cloudimg support.

What is included:

• 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 - no external Redis, PostgreSQL or Elasticsearch dependency
• A unique admin password generated on first boot, written to a root-only credentials file
• A seeded cloudimg_sample_workflow definition so the UI shows workflow content out of the box
• conductor.service and nginx.service as systemd units, enabled and active
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B4ms (4 vCPU / 16 GiB RAM) is a good starting point for the Conductor server plus its embedded SQLite store. NSG inbound: allow 22/tcp from your management network and 80/tcp for the Conductor UI and API (front with TLS for public exposure - 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 cloudimg, and select Create. On Basics 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 Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name conductor \
  --image <marketplace-image-urn> \
  --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 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

The admin password is generated uniquely on the first boot of your VM and written 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 - 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 does not require a login and does not depend on the application being fully started:

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

This 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 the nginx Basic-auth wall - the static /health is the unauthenticated liveness probe.

Step 7 - Sign in to the Conductor UI

Browse to http://<vm-public-ip>/. 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 signing in, open Definitions -> Workflow Definitions. The image ships a seeded cloudimg_sample_workflow definition so you have workflow content to explore immediately, and you can author your own definitions alongside it.

Step 8 - Visualise the workflow diagram

Open the cloudimg_sample_workflow definition to see its task graph rendered as a visual 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 -> Task Definitions to inspect the registered task definitions - the metadata (retry policy, timeouts, rate limits) that Conductor uses when scheduling 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.

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

Step 10 - Verify the admin login from the command line

You can confirm 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

This returns 200 for the correct password (a wrong password, or no credentials, returns 401). The same GET /api/metadata/workflow lists the seeded cloudimg_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 execution history ride 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 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 Certbot's nginx plugin and the engine will be served over HTTPS. Use prose rather than copy-paste here because Certbot prompts interactively for your email and domain; consult the Certbot documentation for the exact certbot --nginx invocation for your domain.

Maintenance

• Service status: systemctl status conductor.service shows the Conductor server; systemctl status nginx.service shows the reverse proxy.
• Logs: journalctl -u conductor.service for the Conductor server logs.
• Restart: 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 and 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

This image is published and supported by cloudimg with 24/7 support. This image bundles the open-source Conductor OSS distribution (Apache License 2.0, conductor-oss/conductor) and is not affiliated with or endorsed by Netflix or the Conductor OSS project.