Build Your First Conductor Workflow in 5 Minutes

Most workflow orchestration tools make you fight the setup before you get to the fun part. Conductor doesn't. You'll go from zero to running a real multi-step workflow — querying live data from GitHub's API — in about five minutes.

Let's do it.

What We're Building

A GitHub Repo Health Checker: you give it any GitHub repo, and it runs three tasks in sequence to fetch the repo's stats, top contributors, and latest releases — then outputs a clean summary.

No mocked APIs. No toy examples. Real HTTP calls, real data.

Step 1: Install the CLI

Pick whichever fits your setup:

npm (if you have Node.js):

npm install -g @conductor-oss/conductor-cli

macOS/Linux (curl):

curl -fsSL https://raw.githubusercontent.com/conductor-oss/conductor-cli/main/install.sh | sh

Windows (PowerShell):

irm https://raw.githubusercontent.com/conductor-oss/conductor-cli/main/install.ps1 | iex

Homebrew:

brew install conductor-oss/conductor/conductor

Verify it worked:

conductor --version

Step 2: Start a Local Server

Here's the part that usually takes 30 minutes in other tools. With Conductor:

conductor server start

That's it. The CLI automatically downloads the Conductor OSS server JAR and starts it on http://localhost:8080. The only prerequisite is Java 21+.

First run takes ~30 seconds to download. After that it starts in seconds.

You now have a full workflow orchestration server running locally.

Step 3: Define the Workflow

Create a file called github-health-check.json:

{

  "name": "github_repo_health_check",

  "description": "Fetch health metrics for any public GitHub repository",

  "version": 1,

  "inputParameters": ["owner", "repo"],

  "tasks": [

    {

      "name": "get_repo_info",

      "taskReferenceName": "get_repo_info_ref",

      "type": "HTTP",

      "inputParameters": {

        "http_request": {

          "uri": "https://api.github.com/repos/${workflow.input.owner}/${workflow.input.repo}",

          "method": "GET",

          "headers": {

            "Accept": "application/vnd.github.v3+json",

            "User-Agent": "conductor-demo"

          }

        }

      }

    },

    {

      "name": "get_contributors",

      "taskReferenceName": "get_contributors_ref",

      "type": "HTTP",

      "inputParameters": {

        "http_request": {

          "uri": "https://api.github.com/repos/${workflow.input.owner}/${workflow.input.repo}/contributors?per_page=5",

          "method": "GET",

          "headers": {

            "Accept": "application/vnd.github.v3+json",

            "User-Agent": "conductor-demo"

          }

        }

      }

    },

    {

      "name": "get_latest_releases",

      "taskReferenceName": "get_releases_ref",

      "type": "HTTP",

      "inputParameters": {

        "http_request": {

          "uri": "https://api.github.com/repos/${workflow.input.owner}/${workflow.input.repo}/releases?per_page=3",

          "method": "GET",

          "headers": {

            "Accept": "application/vnd.github.v3+json",

            "User-Agent": "conductor-demo"

          }

        }

      }

    }

  ],

  "outputParameters": {

    "name": "${get_repo_info_ref.output.response.body.full_name}",

    "description": "${get_repo_info_ref.output.response.body.description}",

    "stars": "${get_repo_info_ref.output.response.body.stargazers_count}",

    "forks": "${get_repo_info_ref.output.response.body.forks_count}",

    "open_issues": "${get_repo_info_ref.output.response.body.open_issues_count}",

    "top_contributors": "${get_contributors_ref.output.response.body}",

    "latest_releases": "${get_releases_ref.output.response.body}"

  },

"schemaVersion": 2

}

A few things worth noticing here:

• 
  ${workflow.input.owner} — input parameters are injected directly into task definitions. No glue code.


• 
  type: "HTTP" — HTTP is a built-in task type. No worker process needed. Conductor handles the call.


• 
  outputParameters — the workflow assembles its final output from task results using the same ${} syntax. get_repo_info_ref.output.response.body.stars drills right into the HTTP response.

Step 4: Register the Workflow

conductor workflow create github-health-check.json

You should see confirmation that it was registered. You can also list all workflows to verify:

conductor workflow list

Step 5: Run It

conductor workflow start \

  --workflow github_repo_health_check \

  --input '{"owner": "conductor-oss", "repo": "conductor"}' \

  --sync

The --sync flag tells the CLI to wait for the workflow to complete and print the result inline. For longer workflows you can drop it and poll with conductor workflow status <id>.

You'll get back something like:

{

  "name": "conductor-oss/conductor",

  "description": "Conductor is a platform for orchestrating microservices and events",

  "stars": 17200,

  "forks": 1843,

  "open_issues": 64,

  "top_contributors": [...],

  "latest_releases": [...]

}

Try it on any public repo — just swap owner and repo.

What Just Happened

You ran a multi-step orchestrated workflow. Three HTTP tasks executed in sequence, each feeding results forward, with the final output assembled automatically from all three.

That might sound simple, but here's what you got for free:

• 
  Retries — if the GitHub API flakes on task 2, Conductor retries it automatically without rerunning task 1.


• 
  Execution history — every run is logged. You can search, inspect, and replay any execution.


• 
  Full observability — conductor workflow get-execution <id> shows you each task's input, output, timing, and status.


• 
  Pauseable, resumable, replayable — you can pause a running workflow, jump to a specific task, skip a failing one, or restart from any point.

Going Further

This workflow runs tasks sequentially, but Conductor supports parallel execution out of the box using fork/join. The contributor and release tasks in this example are actually independent — you could run them simultaneously and cut the total time in half. That's a one-line change to the workflow definition.

A few other things worth exploring from here:

Run workers in any language — use conductor worker stdio to write task logic in Python, Bash, Ruby, or whatever you prefer. JSON in via stdin, result out via stdout. No SDK required.

Schedule it — run this health check on a cron schedule with conductor schedule create, so you get a daily snapshot of any repo you're watching.

Add more steps — extend the workflow with an HTTP POST to Slack or a webhook to notify your team when a repo's open issues spike above a threshold.

The same pattern — define tasks, wire inputs/outputs, run it — scales from this three-task demo to production workflows with hundreds of steps, branching logic, and human approval gates.

Useful Commands to Know

# Check execution status

conductor workflow status <workflow-id>



# Inspect full execution details (inputs, outputs, timing per task)

conductor workflow get-execution <workflow-id>



# Search recent executions

conductor workflow search --workflow github_repo_health_check --count 10



# Retry a failed execution

conductor workflow retry <workflow-id>



# See server logs

conductor server logs -f

The full CLI reference is at github.com/conductor-oss/conductor-cli. If you want to explore what Conductor can do at scale, the Conductor OSS docs cover everything from dynamic fork/join to sub-workflows to event-driven execution.

Star the repo if this was useful — it helps the project a lot.