Concord 2.46.0

Option A: AWS Marketplace console

• Open the SecureAnyCloud Hardened Node.js & Developer and API Tools AMIs listing on AWS Marketplace. Choose View purchase options, then Subscribe. One subscription covers every version in the listing.
• When the subscription is active, choose Launch your software.
• Choose One-click launch from AWS Marketplace, or Launch from EC2 Console for the full launch wizard. In Version, choose Concord 2.46.0 on Ubuntu 24.04, then choose your Region.
• Pick an instance type and your key pair. m5.large is recommended, and the software charge is $0.04 per vCPU per hour.
• Configure the security group to allow SSH (22), HTTP (80) and HTTPS (443). Restrict SSH to your own IP address, and restrict 80 and 443 to the people and API clients that use Concord.
• Choose your VPC and a subnet that gives the instance a public IP. Keep the second (data) volume that the image defines, and leave the metadata defaults, because the image already requires IMDSv2. Then choose Launch.

Option B: AWS CLI

Run this on your own workstation. It creates a security group that allows SSH and HTTPS from your management address only, then launches the instance. Replace the AMI ID with the one shown for your Region on the Marketplace launch page. Replace the VPC, subnet, key pair and CIDR with your own:

SG=$(aws ec2 create-security-group --group-name concord \
  --description "Concord" --vpc-id vpc-0123456789abcdef0 \
  --query GroupId --output text) for p in 22 80 443; do aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port "$p" --cidr <your-mgmt-cidr> done aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids "$SG" \
  --subnet-id subnet-0123456789abcdef0 \
  --associate-public-ip-address \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=concord}]'

You do not need --metadata-options, because the AMI already makes IMDSv2 required. The data volume is part of the AMI. To start with a bigger one, add --block-device-mappings '[{"DeviceName":"/dev/sdf","Ebs":{"VolumeSize":100,"VolumeType":"gp3"}}]' and grow the filesystem as described in Maintenance.

Connect as ubuntu with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>

First boot usually finishes within a minute or two of launch. It creates the certificate, the secrets, the PostgreSQL cluster and the admin key, starts Concord (whose first start creates its database schema), and then gives the agent its own key.

Your credentials are in a root-only file:

sudo cat /root/concord-credentials.txt

# Concord - generated on this instance's first boot by concord-firstboot.service. # Unique to this instance; nothing here shipped in the image. Store it somewhere safe. CONCORD_URL=https://ec2-44-203-91-20.compute-1.amazonaws.com/ CONCORD_CONSOLE_LOGIN_URL=https://ec2-44-203-91-20.compute-1.amazonaws.com/#/login?useApiKey=true CONCORD_ADMIN_USER=admin CONCORD_ADMIN_TOKEN=<your-api-key> # # Open CONCORD_CONSOLE_LOGIN_URL and sign in with the API key above (self-signed certificate minted on this instance; # port 80 redirects). REST API clients send it as the Authorization header: Authorization: <CONCORD_ADMIN_TOKEN>. # The agent has its own key (user 'agent', role agentWebsocket only). Create named API keys for people and # automation, and delete this one once you have your own admin key. # Change the name Concord is served as:
sudo concord-set-hostname <your-dns-name>
# Restrict 80/443 in the security group to the people and clients that need them.
# Guide: https://secureanycloud.com/stacks/concord-2-46-0/

Your file shows your instance's own name and a 32-character key in place of <your-api-key>.

systemctl is-active concord-port-guard postgresql@16-main concord-server concord-agent nginx curl -s --cacert /etc/ssl/sac/concord.crt https://localhost/healthz; echo curl -s --cacert /etc/ssl/sac/concord.crt https://localhost/api/v1/server/version; echo curl -s -o /dev/null -w 'without a key: %{http_code}\n' --cacert /etc/ssl/sac/concord.crt https://localhost/api/v1/org curl -s --cacert /etc/ssl/sac/concord.crt https://localhost/api/v1/server/version | grep -q '"version":"2.46.0"'

active active active active active {"ok":true} {"version":"2.46.0","commitId":"e5d500485bc83bd0fee123b6534837bb43b4f97c","env":"n/a","ok":true} without a key: 401

Only SSH, HTTP and HTTPS are reachable from outside. Concord's port 8001 is dropped for anything but loopback, and PostgreSQL and the agent's maintenance port listen on loopback only:

sudo ss -Hltn | awk '{print $4}' | sort
sudo nft list chain inet sac_concord input | grep -q 'iifname != "lo" tcp dport { 5432, 8001, 8010 }'

0.0.0.0:22 0.0.0.0:443 0.0.0.0:80 0.0.0.0:8001 127.0.0.1:5432 127.0.0.1:8010 127.0.0.53%lo:53 127.0.0.54:53 [::]:22 [::]:443 [::]:80

• Open CONCORD_CONSOLE_LOGIN_URL from the credentials file in your browser. The certificate is self-signed for your instance, so your browser asks you to accept it the first time. You can also use your own certificate (Step 9).
• The sign-in page opens in API key mode. Paste the value of CONCORD_ADMIN_TOKEN and choose Login.
• You are signed in as admin. The console shows your processes, the Default organisation with its projects, secrets and teams, and your profile, where you can create more API keys.

From the command line, the same key authenticates the REST API in the Authorization header:

H="Authorization: $(sudo sed -n 's/^CONCORD_ADMIN_TOKEN=//p' /root/concord-credentials.txt)" curl -s --cacert /etc/ssl/sac/concord.crt -H "$H" https://localhost/api/service/console/whoami; echo curl -s --cacert /etc/ssl/sac/concord.crt -H "$H" https://localhost/api/service/console/whoami | grep -q '"username":"admin"'

{"realm":"apikey","username":"admin","displayName":"admin","orgs":[{"id":"0fac1b18-d179-11e7-b3e7-d7df4543ed4f","name":"Default"}]}

Write a flow and send it to Concord. The agent picks it up and runs it, and Concord keeps the log:

H="Authorization: $(sudo sed -n 's/^CONCORD_ADMIN_TOKEN=//p' /root/concord-credentials.txt)"
D=$(mktemp -d) && cd "$D" printf 'configuration:\n runtime: concord-v2\nflows:\n default:\n - log: "Hello from Concord"\n - log: "Running as ${initiator.username} in process ${txId}"\n' > concord.yml
ID=$(curl -s --cacert /etc/ssl/sac/concord.crt -H "$H" -F concord.yml=@concord.yml https://localhost/api/v1/process | python3 -c 'import json,sys; print(json.load(sys.stdin)["instanceId"])') for i in $(seq 1 60); do
S=$(curl -s --cacert /etc/ssl/sac/concord.crt -H "$H" https://localhost/api/v1/process/$ID | python3 -c 'import json,sys; print(json.load(sys.stdin)["status"])'); case "$S" in FINISHED|FAILED|CANCELLED) break ;; esac; sleep 2; done echo "status=$S" curl -s --cacert /etc/ssl/sac/concord.crt -H "$H" https://localhost/api/v1/process/$ID/log | grep -E 'Hello|Running as|finished' cd / && rm -rf "$D" [ "$S" = FINISHED ]

status=FINISHED 2026-10-27T15:53:09.017+0000 [INFO ] Hello from Concord 2026-10-27T15:53:09.137+0000 [INFO ] Running as admin in process c3ed2e7a-3ca3-47c2-8059-ec6933741c46 2026-10-27T15:53:11.028+0000 [INFO ] Process finished with: 0

The first flow takes a few seconds longer because the agent downloads Concord's standard task plugins from Maven Central and caches them. The process also appears in the console under Processes, with its log, its status history and its variables.

The flow ran as concord-flow, the account that runs every flow. sudo sac-concord-probe runs the same check end to end and prints CONCORD_PROBE_OK. It confirms that the key is accepted, that a missing key and a wrong key are refused, that the agent is connected and that a test flow finished.

Most teams keep their flows in Git. Create a project, register a repository and start its flow. This example uses the "hello world" example from Concord's own repository:

H="Authorization: $(sudo sed -n 's/^CONCORD_ADMIN_TOKEN=//p' /root/concord-credentials.txt)" C=(-s --cacert /etc/ssl/sac/concord.crt -H "$H") curl "${C[@]}" -H 'Content-Type: application/json' -d '{"name":"examples","visibility":"PRIVATE"}' https://localhost/api/v1/org/Default/project; echo curl "${C[@]}" -H 'Content-Type: application/json' -d '{"name":"hello","url":"https://github.com/walmartlabs/concord.git","branch":"master","path":"examples/hello_world"}' https://localhost/api/v1/org/Default/project/examples/repository; echo
ID=$(curl "${C[@]}" -F org=Default -F project=examples -F repo=hello https://localhost/api/v1/process | python3 -c 'import json,sys; print(json.load(sys.stdin)["instanceId"])') for i in $(seq 1 60); do
S=$(curl "${C[@]}" https://localhost/api/v1/process/$ID | python3 -c 'import json,sys; print(json.load(sys.stdin)["status"])'); case "$S" in FINISHED|FAILED|CANCELLED) break ;; esac; sleep 2; done echo "status=$S" curl "${C[@]}" https://localhost/api/v1/process/$ID/log | grep -E 'Hello|finished' [ "$S" = FINISHED ]

{"id":"01a17e10-cfff-73fc-b28c-84a7db7a26e4","result":"CREATED","ok":true} {"result":"CREATED","ok":true} status=FINISHED 2026-10-27T15:53:34.731+0000 [INFO ] Hello, Concord! 2026-10-27T15:53:36.125+0000 [INFO ] Process finished with: 0

For a private repository, store its credentials as a Concord secret (in the console: Organizations, Default, Secrets). Pick that secret when you add the repository.

Concord can also start a repository's flow from a plain link, https://<your-host>/api/v1/org/<org>/project/<project>/repo/<repo>/start/<entry-point>. The console offers this link as Start process. A link like that could be planted on another web site to start a process with your session, so nginx accepts it only when the request comes from Concord's own pages. Scripts send Sec-Fetch-Site: same-origin, or use POST /api/v1/process as above:

H="Authorization: $(sudo sed -n 's/^CONCORD_ADMIN_TOKEN=//p' /root/concord-credentials.txt)" U=https://localhost/api/v1/org/Default/project/examples/repo/hello/start/default
X=$(curl -s -o /dev/null -w '%{http_code}' --cacert /etc/ssl/sac/concord.crt -H "$H" -H 'Sec-Fetch-Site: cross-site' "$U"); echo "cross-site link: $X"
O=$(curl -s -o /dev/null -w '%{http_code}' --cacert /etc/ssl/sac/concord.crt -H "$H" -H 'Sec-Fetch-Site: same-origin' "$U"); echo "same-origin: $O" [ "$X" = 403 ] && [ "$O" = 200 ]

cross-site link: 403 same-origin: 200

Create a named key for each person and each automation instead of sharing the first-boot key. Run this as admin:

H="Authorization: $(sudo sed -n 's/^CONCORD_ADMIN_TOKEN=//p' /root/concord-credentials.txt)" curl -s --cacert /etc/ssl/sac/concord.crt -H "$H" -H 'Content-Type: application/json' \
  -d '{"username":"admin","name":"my-laptop"}' https://localhost/api/v2/apikey

{"id":"01a17d38-1a27-70f0-bbec-21594449fb1d","name":"my-laptop","key":"<your-new-api-key>","result":"CREATED","ok":true}

The key is shown once, so store it safely. Users sign in to the console with their own key, the same way as in Step 4.

To add a person, create a local user (POST /api/v1/user with {"username":"alice","type":"LOCAL"}), give them roles or team membership, and create a key for them. You can also create and delete keys in the console under the user's API keys.

Once you have your own admin key, delete the first-boot key named sac-admin (DELETE /api/v2/apikey/<id>; list keys with GET /api/v1/apikey) and remove it from /root/concord-credentials.txt.

JSON stores keep structured data that flows and API clients share. Create a store, write an item and read it back:

H="Authorization: $(sudo sed -n 's/^CONCORD_ADMIN_TOKEN=//p' /root/concord-credentials.txt)" C=(-s --cacert /etc/ssl/sac/concord.crt -H "$H" -H 'Content-Type: application/json') curl "${C[@]}" -d '{"name":"inventory"}' https://localhost/api/v1/org/Default/jsonstore; echo curl "${C[@]}" -X PUT -d '{"hosts":["web-1","web-2"]}' https://localhost/api/v1/org/Default/jsonstore/inventory/item/servers; echo curl "${C[@]}" https://localhost/api/v1/org/Default/jsonstore/inventory/item/servers; echo curl "${C[@]}" https://localhost/api/v1/org/Default/jsonstore/inventory/item/servers | grep -q '"web-2"'

{"result":"CREATED","ok":true} {"result":"CREATED","ok":true} {"hosts": ["web-1", "web-2"]}

JSON-store queries are disabled by default. Concord can also run SQL queries over a store's items, but that feature is not safe for multi-organisation use, so it is switched off on this image. A query is refused with permission denied, while stores and items keep working.

sudo concord-jsonstore-queries status
sudo concord-jsonstore-queries status | grep -qx 'JSON-store queries: disabled'

JSON-store queries: disabled

Switch queries on only if every Concord user on this instance may see every organisation's JSON-store data, for example when a single team uses only the Default organisation. Run this as root:

sudo concord-jsonstore-queries enable
# queries run; not safe for multi-organisation use
sudo concord-jsonstore-queries disable
# back to the default

First boot created the certificate for the instance's public DNS name, public IP, private IP and localhost. The key, the configuration, the credentials file and the data directories are readable only by their owners. Inspect the certificate:

sudo openssl x509 -in /etc/ssl/sac/concord.crt -noout -subject -ext subjectAltName
sudo stat -c '%a %U:%G %n' /etc/ssl/sac/concord.key /etc/concord/server.conf /etc/concord/agent.conf /root/concord-credentials.txt /var/lib/concord/postgresql /var/lib/concord/server /var/lib/concord/agent

subject=CN = ec2-44-203-91-20.compute-1.amazonaws.com, O = sac X509v3 Subject Alternative Name: DNS:ec2-44-203-91-20.compute-1.amazonaws.com, IP Address:44.203.91.20, IP Address:172.31.94.172, IP Address:127.0.0.1, DNS:localhost 600 root:root /etc/ssl/sac/concord.key 640 root:concord /etc/concord/server.conf 640 root:concord-agent /etc/concord/agent.conf 600 root:root /root/concord-credentials.txt 700 postgres:postgres /var/lib/concord/postgresql 750 concord:concord /var/lib/concord/server 2750 concord-agent:concord-work /var/lib/concord/agent

To serve Concord under your own DNS name, such as concord.example.com pointed at this instance, run the helper. It records the name and creates a new self-signed certificate for it. It also updates nginx, Concord's allowed origin and the cross-site guard, rewrites the URLs in the credentials file and restarts Concord:

sudo concord-set-hostname concord.example.com

If the instance's public address changes after a stop and start, run the helper again.

To use a certificate from your own certificate authority, replace /etc/ssl/sac/concord.key (keep it 0600 root) and /etc/ssl/sac/concord.crt, then run sudo systemctl reload nginx. Do this before other people sign in.

Concord clones the repositories you register, and the agent downloads task plugins from Maven Central, so the instance needs outbound HTTPS. None of Concord's services, nginx or PostgreSQL can reach the instance metadata service. The Amazon Time Sync Service at 169.254.169.123 keeps working, and the firmware-metadata refresh is masked:

systemctl show -p IPAddressDeny concord-server.service concord-agent.service nginx.service postgresql@16-main.service chronyc -n sources | grep 169.254
FW=$(systemctl is-enabled fwupd-refresh.timer fwupd-refresh.service || true); echo "$FW" [ "$(sort -u <<<"$FW")" = masked ] && [ "$(systemctl show -p IPAddressDeny --value concord-server.service concord-agent.service nginx.service postgresql@16-main.service | grep -c 169.254.169.254)" = 4 ]

IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128 IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128 IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128 IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128 ^* 169.254.169.123 3 4 377 13 -23us[ +21us] +/- 433us masked masked

If your flows need AWS credentials, store them as Concord secrets, or use a dedicated IAM user's keys, rather than the instance role. Flows cannot read the instance role from the metadata service.