Concord 2.44
Overview
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 it through a REST API or its web Console, queues it, and hands it to a pluggable agent that executes each step. Teams use flows to codify provisioning, deployment, approvals and scheduled jobs as repeatable automation.
This SecureAnyCloud image runs the official Concord 2.44.0 server and agent distributions (com.walmartlabs.concord, Apache-2.0) on OpenJDK 21 and Ubuntu 24.04 LTS on Azure. The distributions are verified against sha256 checksums at build time. 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. 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 you get:
- 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.servicesystemd unit hosting the REST API and the Console web UI on the loopback interfaceconcord-agent.servicesystemd unit that connects to the server and executes flowsconcord-firstboot.servicesystemd 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:80redirecting to:443, reverse proxying the Console, REST API and websocket to the server - An unauthenticated
/healthzendpoint (HTTP 200) wired to the server ping for load balancer and probe checks - All Concord state on a dedicated 30 GiB Azure data disk mounted at
/var/lib/concord - Ubuntu 24.04 LTS base with the latest security patches applied at build time and unattended security updates enabled
- Azure Linux Agent for cloud integration and SSH key injection
- 24/7 SecureAnyCloud 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. Port :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.
Deploy the image
Launch the Concord 2.44 on Ubuntu 24.04 LTS image by SecureAnyCloud 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.
When the VM is running, connect over SSH as azureuser with the SSH key you selected at launch:
ssh azureuser@<public-ip>Confirm the services are running
The database, server, agent and nginx start automatically on boot. Confirm that all four are active:
systemctl is-active postgresql concord-server concord-agent nginxEach service should print active. For the full status view, run:
systemctl --no-pager status concord-server concord-agent nginx | grep -E 'concord-server|concord-agent|nginx.service|Active:' | headRetrieve the per-VM administrator API token
Concord authenticates the Console and REST API with an administrator API token. The token is unique to your VM and is generated on first boot. Read it from the credentials file:
sudo cat /var/lib/sac/secrets/sac-credentials.txtThe CONCORD_ADMIN_TOKEN value is your administrator credential. Keep it secret, because it grants full administrative access to Concord.
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.
Check the REST API and your identity
Call the server ping endpoint, which is unauthenticated and confirms that the API is live. Then call the whoami endpoint, which returns the identity behind your token. It should report the admin user:
TOKEN=$(sudo grep '^CONCORD_ADMIN_TOKEN=' /var/lib/sac/secrets/sac-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/whoamiAn unauthenticated request to whoami, or one with a wrong token, is rejected with HTTP 401. The image ships no default credential.
Run your first workflow
Submit a minimal flow as an ad-hoc process and watch the agent execute it:
TOKEN=$(sudo grep '^CONCORD_ADMIN_TOKEN=' /var/lib/sac/secrets/sac-credentials.txt | cut -d= -f2-)
cat > /tmp/concord.yml <<'YML' flows: default: - log: "Hello from the sac 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 through NEW -> STARTING -> FINISHED. 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.
Track processes from the dashboard
Open the Console Activity page. It lists your most recent processes with their status, so you can see workflow runs at a glance.
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.
Where the data lives
All Concord state is held in PostgreSQL. That state covers processes, projects, organisations, the secret store and the audit log. The PostgreSQL cluster is relocated onto the dedicated Azure data disk mounted at /var/lib/concord. Confirm that 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. Your automation state therefore survives independently of the OS disk, and you can resize the volume 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 | headThe 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 in production. Sign in to the Console, create a new API key under the
adminuser, and remove the first-boot key. - Reach the REST API and Console only over
:443(nginx, TLS). The server's:8001and PostgreSQL's:5432bind 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
- The Console shows a certificate warning. This is expected, because the image generates a per-VM self-signed certificate. Install a CA-issued certificate for production.
whoamireturns 401. Confirm that you are sending the exactCONCORD_ADMIN_TOKENfrom/var/lib/sac/secrets/sac-credentials.txtin theAuthorizationheader.- A process stays in
ENQUEUED. Confirm that the agent is running withsystemctl is-active concord-agent. The agent pulls work from the server's process queue. - Inspect the logs with
journalctl -u concord-serverandjournalctl -u concord-agent.
Support
SecureAnyCloud images come with 24/7 support and a guaranteed 24 hour response SLA. Contact support through the Azure Marketplace listing or at secureanycloud.com.
Deploy on Azure
Launch Concord 2.44 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