Concord 2.44 on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of Concord 2.44 on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Concord is an open source workflow orchestration server from Walmart (walmartlabs/concord, Apache-2.0) that automates operational processes as version controlled flows. A flow is a YAML process the server accepts through a REST API or its web Console, queues, and hands to a pluggable agent that executes each step, so teams can codify provisioning, deployment, approvals and scheduled jobs as repeatable automation.

The image runs the official Concord 2.44.0 server and agent distributions (com.walmartlabs.concord, Apache-2.0), verified against sha256 checksums at build time, on OpenJDK 21. The server hosts the REST API and the React Console web UI; the agent executes the flows; and a bundled PostgreSQL 16 database holds all state. The appliance is secure by default: the database ships empty and, on first boot, Concord mints a unique administrator API token, generates a per VM TLS certificate and rotates the internal service secrets, so no default login exists anywhere in the image.

What is included:

• Concord Server 2.44.0 and Concord Agent 2.44.0 (com.walmartlabs.concord, Apache-2.0), sha256-pinned distributions from Maven Central
• OpenJDK 21 JRE headless (runs the Java 17 compatible Concord artifacts)
• Bundled PostgreSQL 16 with its cluster relocated onto a dedicated Azure data disk at /var/lib/concord
• concord-server.service systemd unit hosting the REST API and the Console web UI on the loopback interface
• concord-agent.service systemd unit that connects to the server and executes flows
• concord-firstboot.service systemd oneshot that mints the per-VM administrator API token, rotates all internal secrets and generates a per-VM TLS certificate before anything is exposed
• nginx fronting :443 (per-VM self-signed certificate) with :80 redirecting to :443, reverse proxying the Console, REST API and websocket to the server
• An unauthenticated /healthz endpoint (HTTP 200) wired to the server ping for load balancer / probe checks
• All Concord state on a dedicated 30 GiB Azure data disk mounted at /var/lib/concord
• Ubuntu 24.04 LTS base with latest security patches applied at build time and unattended security updates enabled
• Azure Linux Agent for seamless cloud integration and SSH key injection
• 24/7 cloudimg support with guaranteed 24 hour response SLA

Architecture

The Concord server listens on 127.0.0.1:8001 for the REST API and the Console. nginx terminates :443 with a per-VM self-signed certificate and reverse proxies the Console, the REST API and the live-log websocket to the server; :80 redirects to :443. The agent connects to the server over the loopback interface and pulls work from the process queue. The Azure Network Security Group opens only ports 22, 80 and 443, so the API and database are never exposed directly.

Step 1: Deploy the image

Launch the Concord 2.44 on Ubuntu 24.04 LTS by cloudimg image from the Azure Marketplace on a Standard_B2s (or larger) VM. Open inbound ports 22 (SSH), 80 (HTTP) and 443 (HTTPS) in the Network Security Group. The 30 GiB data disk that carries the Concord database is provisioned automatically from the image.

Once the VM is running, connect over SSH as azureuser with the SSH key you selected at launch:

ssh azureuser@<public-ip>

Step 2: Confirm the services are running

The database, server, agent and nginx start automatically on boot. Confirm all four are active:

systemctl is-active postgresql concord-server concord-agent nginx

Each command should print active. For the full status view:

systemctl --no-pager status concord-server concord-agent nginx | grep -E 'concord-server|concord-agent|nginx.service|Active:' | head

Step 3: Retrieve the per-VM administrator API token

Concord authenticates the Console and REST API with an administrator API token that is unique to your VM and generated on first boot. Read it from the credentials file:

sudo cat /etc/cloudimg-credentials.txt

The CONCORD_ADMIN_TOKEN value is your administrator credential. Keep it secret — it grants full administrative access to Concord.

Step 4: Open the Concord Console

Browse to https://<public-ip>/ and accept the per-VM self-signed certificate. Concord shows its login card. Choose Login with API Key, paste the CONCORD_ADMIN_TOKEN from the previous step, and sign in as the admin user. (You can also open the API-key login directly at https://<public-ip>/#/login?useApiKey=true.)

Step 5: Check the REST API and your identity

The server ping endpoint is unauthenticated and confirms the API is live. The whoami endpoint returns the identity behind your token — it should report the admin user:

TOKEN=$(sudo grep '^CONCORD_ADMIN_TOKEN=' /etc/cloudimg-credentials.txt | cut -d= -f2-)
curl -ks https://127.0.0.1/api/v1/server/ping
echo
curl -ks -H "Authorization: ${TOKEN}" https://127.0.0.1/api/service/console/whoami

An unauthenticated request to whoami, or one with a wrong token, is rejected with HTTP 401 — the image ships no default credential.

Step 6: Run your first workflow

Concord exists to run workflows. Submit a minimal flow as an ad-hoc process and watch the agent execute it:

TOKEN=$(sudo grep '^CONCORD_ADMIN_TOKEN=' /etc/cloudimg-credentials.txt | cut -d= -f2-)
cat > /tmp/concord.yml <<'YML'
flows:
  default:
    - log: "Hello from the cloudimg Concord appliance"
    - log: "Workflow executed by concord-agent"
YML
RESP=$(curl -ks -H "Authorization: ${TOKEN}" -F concord.yml=@/tmp/concord.yml https://127.0.0.1/api/v1/process)
IID=$(echo "$RESP" | sed -n 's/.*"instanceId"[: ]*"\([^"]*\)".*/\1/p')
echo "Started process ${IID}"
for i in $(seq 1 40); do
  ST=$(curl -ks -H "Authorization: ${TOKEN}" "https://127.0.0.1/api/v1/process/${IID}" | sed -n 's/.*"status"[: ]*"\([^"]*\)".*/\1/p')
  echo "status=${ST}"
  case "$ST" in FINISHED|FAILED|CANCELLED|TIMED_OUT) break ;; esac
  sleep 3
done
curl -ks -H "Authorization: ${TOKEN}" "https://127.0.0.1/api/v1/process/${IID}/log"

The process moves NEW -> STARTING -> FINISHED, and the log shows the agent acquiring the process, resolving its runtime dependencies, and printing the flow's own log lines ending with Process finished with: 0.

The same run is visible in the Console. Open the process from the dashboard and select the Logs tab:

Step 7: Track processes from the dashboard

The Console Activity page lists your most recent processes with their status, so you can see workflow runs at a glance:

Step 8: Organise projects and secrets

Concord groups projects, repositories, secrets and teams under organisations. The image ships with the built-in Default organisation, ready for you to add projects and Git-backed flow repositories:

Step 9: Where the data lives

All Concord state — processes, projects, organisations, the secret store and the audit log — is held in PostgreSQL, whose cluster is relocated onto the dedicated Azure data disk mounted at /var/lib/concord. Confirm the running cluster is on the data disk:

mountpoint /var/lib/concord
sudo -u postgres psql -tAqc 'SHOW data_directory'

The data directory is /var/lib/concord/pgdata, so your automation state survives independently of the OS disk and the volume can be resized on its own.

Managing the service

Restart or check the Concord services with systemd:

sudo systemctl restart concord-server
sudo systemctl restart concord-agent
sudo systemctl status concord-server --no-pager | head

The server heap is tuned for a Standard_B2s (2 vCPU / 4 GB) VM. For heavier workflow throughput, launch on a larger VM size — the services pick up the additional memory automatically.

Security notes

• No default credential. The database ships empty; first boot mints a unique administrator API token, rotates the internal service and database secrets, and generates a per-VM TLS certificate. There is no shared password anywhere in the image.
• Rotate the administrator token for production use: sign in to the Console, create a new API key under the admin user, and remove the first-boot one.
• The REST API and Console are only reachable over :443 (nginx, TLS); the server's :8001 and PostgreSQL's :5432 bind to the host and are firewalled by the Network Security Group, which opens only 22, 80 and 443.
• Replace the per-VM self-signed certificate under /etc/nginx/ssl/ with a CA-issued certificate for your DNS name in production.
• Keep the VM patched — unattended security updates are enabled by default.

Troubleshooting

• Console shows a certificate warning: expected — the image generates a per-VM self-signed certificate. Install a CA-issued certificate for production.
• whoami returns 401: confirm you are sending the exact CONCORD_ADMIN_TOKEN from /etc/cloudimg-credentials.txt in the Authorization header.
• A process stays in ENQUEUED: confirm the agent is running with systemctl is-active concord-agent; the agent pulls work from the server's process queue.
• Inspect logs: journalctl -u concord-server and journalctl -u concord-agent.

Support

cloudimg images come with 24/7 support and a guaranteed 24 hour response SLA. Contact support through the Azure Marketplace listing or at cloudimg.co.uk.