Deployment guide

Operaton

Overview

Operaton is an open-source, community-driven workflow and decision automation engine, and the continuation of Camunda 7. It executes BPMN 2.0 processes and DMN decision tables through a persistent process engine. It ships three web apps, plus a full REST API: Cockpit for operating and monitoring, Tasklist for human tasks, and Admin for users, groups and authorizations.

The SecureAnyCloud image runs the free, open-source Apache-2.0 engine (operaton/operaton, the self-contained distribution) as the upstream container, which is the officially supported way. A bundled PostgreSQL holds durable state. Docker Compose orchestrates both under systemd, and nginx fronts them. Both container images are pinned by digest and captured into the VM, so your instance starts in seconds.

The engine is secure from the first request. A unique admin password and a unique database password are generated for each VM on first boot, before the port is reachable. The image ships with no default demo account and the REST API is locked behind authentication. It is backed by 24/7 SecureAnyCloud support.

Operaton is a trademark of its respective owner. This image is produced by SecureAnyCloud and is not affiliated with, endorsed by, or sponsored by the Operaton project or Camunda. It ships only the free, open-source Apache-2.0 engine.

What you get:

Operaton 2.1.2 (the Apache-2.0 BPMN and DMN engine, operaton/operaton), pinned by image digest.
A bundled PostgreSQL 16 for durable process and history state, pinned by image digest and never exposed on a host port.
The Cockpit, Tasklist and Admin web apps and the /engine-rest REST API, fronted by nginx on port 80.
A unique admin password and PostgreSQL password generated for each VM on first boot.
No default demo account, the invoice example app disabled, and REST API authentication and resource authorization turned on.
Ubuntu 24.04 LTS, patched at build time.

Prerequisites

An Azure subscription.
SSH access to the VM (an SSH key pair) and a client for the web apps (any modern browser).
Inbound TCP 22 (SSH) and 80 (web apps and REST API) open on the VM's network security group.

Step 1 - Deploy from the Azure Marketplace

Find the Operaton on Ubuntu 24.04 offer by SecureAnyCloud in the Azure Marketplace, and select Get It Now. Choose your subscription, resource group and region.

Select the recommended Standard_B2s size, or a larger size for heavier workloads. Allow inbound ports 22 and 80, and then create the VM.

Step 2 - Deploy from the Azure CLI

To deploy with the Azure CLI instead, replace the image URN with the one shown on the offer page:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:operaton:default:latest
az vm create \
  --resource-group my-rg \
  --name operaton \
  --image sac1647283583153:operaton:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
az vm open-port --resource-group my-rg --name operaton --port 80 --priority 900

Step 3 - Connect to your VM

Connect over SSH as azureuser with the key you supplied at deploy time:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

On first boot, the image generates a unique admin password and database password, initialises a clean PostgreSQL database, creates a single administrator user, and starts the engine. Confirm that the systemd services are active and that both containers (the engine and the bundled PostgreSQL) are healthy:

systemctl is-active docker operaton nginx
sudo docker ps --format 'table {{.Names}}\t{{.Status}}'

All three services report active, and both operaton-operaton-1 and operaton-postgres-1 report healthy.

The engine is published to the loopback interface only and fronted by nginx. The bundled PostgreSQL is never exposed on a host port. The public liveness endpoint returns 200 with no credentials:

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

Step 5 - Secure by default: authentication gates everything

The engine ships locked down. There is no default demo account, and every request to the REST API without valid credentials is rejected with 401. Confirm it yourself with the request below, which sends no credentials:

curl -s -o /dev/null -w 'no credentials: HTTP %{http_code}\n' http://127.0.0.1/engine-rest/user

It returns HTTP 401. The default demo/demo account does not exist, and a weak admin/admin password is rejected too. Only the unique per-VM admin password authenticates, and the public health endpoint stays open.

Your unique admin password is written to /root/operaton-credentials.txt, which only root can read:

sudo stat -c '%a %U:%G' /root/operaton-credentials.txt

It reports 600 root:root. View the notes with the command below. They include your admin password, the web app URLs and the REST endpoint.

sudo cat /root/operaton-credentials.txt

Step 6 - Log in to the web apps

Browse to http://<vm-public-ip>/operaton/. Operaton redirects you to the login page, which gates all three web apps. Nothing loads until you sign in.

Sign in with the username admin and the password from /root/operaton-credentials.txt. Cockpit opens on its dashboard. The dashboard shows running process instances, open incidents, open human tasks, and a summary of everything deployed.

Use the Processes view to inspect a deployed BPMN process. It shows the live diagram, the number of running instances, and the individual instances with their business keys.

Step 7 - Deploy and run a BPMN process over the REST API

Everything you can do in the web apps, you can also do over the /engine-rest REST API, authenticated with your admin credentials. The image ships a minimal example process at /etc/operaton/sac-roundtrip.bpmn.

The commands below read your admin password from the notes file, so it never appears on screen. They deploy the process and start an instance, which is an authenticated, end-to-end BPMN round trip against the bundled PostgreSQL:

PW=$(sudo grep '^OPERATON_ADMIN_PASSWORD=' /root/operaton-credentials.txt | cut -d= -f2-)
curl -s -u "admin:$PW" \
  -F 'deployment-name=guide-check' \
  -F 'enable-duplicate-filtering=true' \
  -F 'data=@/etc/operaton/sac-roundtrip.bpmn' \
  http://127.0.0.1/engine-rest/deployment/create | jq '{id, name}'
curl -s -u "admin:$PW" -H 'Content-Type: application/json' \
  -X POST -d '{"businessKey":"guide-demo"}' \
  http://127.0.0.1/engine-rest/process-definition/key/sacRoundtrip/start | jq '{id, ended}'

The deploy call returns the new deployment ID, and the start call returns the process instance ID. Together they prove an authenticated BPMN action over the engine. From your own machine, substitute your VM public IP and your admin password:

curl -u 'admin:<OPERATON_ADMIN_PASSWORD>' \
  http://<vm-public-ip>/engine-rest/process-definition/count

Step 8 - Manage users

Open the Admin web app to manage users, groups, tenants and authorizations. The image ships a single administrator account, admin, with no demo, john or mary accounts, so there is nothing to clean up.

To change the admin password, edit the account under Users, then admin, then Account. Keep /root/operaton-credentials.txt in sync for your own records. Add further users and grant them authorizations from the same web app.

Step 9 - Production: your own domain with TLS

For production, put your own DNS name in front of the VM and terminate TLS. Install a certificate with your preferred tool, such as Certbot with the nginx plugin, and then front the engine on port 443. Because Operaton derives request URLs from the incoming Host header, no application configuration change is needed.

When you serve the web apps over HTTPS, enable secure session cookies. Set server.servlet.session.cookie.secure: true in /etc/operaton/default.yml, and restart with sudo systemctl restart operaton.

Support

This image is built and supported by SecureAnyCloud. If you need help, contact support through the SecureAnyCloud listing on the Azure Marketplace.

Operaton is free, open-source software under the Apache License 2.0. The SecureAnyCloud image adds first-boot secret generation, a bundled PostgreSQL, security hardening and 24/7 support.

Deploy on Azure

Launch Operaton 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

Deploy on Azure

Overview

Operaton is the open-source, community-driven continuation of Camunda 7, a mature BPMN 2.0 workflow and DMN decision automation engine. It executes business processes and decision tables, and tracks their state and history. It ships three web applications, plus a full REST API for driving the engine from your own applications: Cockpit for monitoring, Tasklist for human tasks, and Admin for users and authorizations.

This guide covers deploying and configuring Operaton on AWS from the SecureAnyCloud AWS Marketplace AMI. The image runs the free, open-source, Apache-2.0-licensed Operaton Run distribution as the upstream container, pinned by image digest, which is the officially supported way. A bundled PostgreSQL database, also pinned by digest, keeps your process instances, decisions and history durable across restarts, unlike the default embedded in-memory database. Both images are captured into the AMI, so your instance starts in seconds.

Operaton, like Camunda 7, normally ships a default demo/demo administrator and an example application that seeds further demo users and data. Nothing here ships with a known secret. The demo account and the example application are removed, and REST authentication and resource authorizations are turned on. A single administrator account with a random password is generated for each instance on first boot, before the engine is reachable, and written to a root-only file. The image is backed by 24/7 SecureAnyCloud support.

Operaton is a trademark of its respective owners, and Camunda is a trademark of Camunda Services GmbH. This image is produced by SecureAnyCloud and is not affiliated with, endorsed by, or sponsored by either. It ships the free, open-source, Apache-2.0-licensed self-hosted software, unmodified.

What you get:

Operaton Run 2.1.2 (the Apache-2.0-licensed engine, the Cockpit, Tasklist and Admin web apps, and the REST API), pinned by image digest.
PostgreSQL 16 (the bundled database for durable engine state), pinned by image digest.
Docker Engine, with the engine published to the loopback interface only and PostgreSQL not exposed to any host port, fronted by nginx on port 80.
docker.service, operaton-firstboot.service, operaton.service and nginx.service as systemd units, enabled and active on boot.
A single administrator account with a random password, plus a random PostgreSQL password, generated per instance on first boot and never baked into the image.
The demo administrator and the example application removed, with REST authentication and resource authorizations turned on.
No default login, no shipped secret, and an empty database on first boot.
An Ubuntu 24.04 LTS base with the latest security patches applied at build time.
24/7 SecureAnyCloud support with a guaranteed 24-hour response SLA.

Prerequisites

An active AWS account and an EC2 key pair in your target Region.
A subscription to the Operaton listing on AWS Marketplace.
A VPC and subnet, and a security group that allows inbound 22/tcp (SSH, from your admin network) and 80/tcp (the web apps and REST API, from the networks that use them).

Recommended instance type: m5.large (2 vCPU, 8 GB RAM) is a sensible starting point. The engine runs a JVM alongside PostgreSQL, so a general-purpose instance with a few gigabytes of RAM is appropriate. Use a larger instance for high process throughput or many concurrent users.

Connecting to your instance

Connect over SSH using your EC2 key pair. On Ubuntu 24.04 LTS, the default login user is ubuntu, for example ssh -i your-key.pem ubuntu@<instance-public-ip>.

Subscribe and launch from AWS Marketplace

Sign in to the AWS Marketplace and search for Operaton by SecureAnyCloud. Choose Continue to Subscribe, then Continue to Configuration, then Continue to Launch.

Pick your Region, the m5.large instance type, your VPC and subnet, and your EC2 key pair. Choose a security group that allows SSH (22) from your admin network and HTTP (80) from the networks that use the engine. Launch the instance.

Launch from the AWS CLI

To launch the AMI directly instead, resolve the product AMI ID for your Region from the listing, and then run:

REGION="us-east-1" AMI_ID="<ami-id>"
# the Operaton AMI id for your region KEY_NAME="your-key" SG_ID="sg-xxxxxxxx"
# allows 22 from your admin CIDR and 80 from your users SUBNET_ID="subnet-xxxxxxxx" aws ec2 run-instances --region "$REGION" --image-id "$AMI_ID" \
  --instance-type m5.large --key-name "$KEY_NAME" \
  --security-group-ids "$SG_ID" --subnet-id "$SUBNET_ID" \
  --metadata-options 'HttpTokens=required,HttpEndpoint=enabled' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=operaton}]'

The instance boots, generates its per-instance secrets, and starts the engine automatically. Allow a couple of minutes on first boot while the engine creates its database schema.

Connect to your instance

Connect over SSH as the login user for your OS variant. For Ubuntu, run ssh -i your-key.pem ubuntu@<instance-public-ip>.

Confirm the services are running

The stack runs as two containers under one operaton.service: the Operaton engine and its bundled PostgreSQL database. nginx fronts them. Confirm that the services are active and list the containers. nginx listens on :80, the engine is published to 127.0.0.1:8080 only, and PostgreSQL is not exposed to any host port:

sudo systemctl is-active docker operaton nginx
sudo docker compose -f /etc/operaton/compose.yaml ps

The services report active, and the two containers report running and healthy. The engine (127.0.0.1:8080) is bound only to the loopback interface. PostgreSQL runs inside the private Compose network with no host port. nginx on :80 is the single public front door.

Read the per-instance credentials

First boot generated a single administrator account with a random password, plus a random PostgreSQL password, for this instance. It did so before the engine was reachable, and wrote them to a root-only file. Read the file:

sudo cat /root/operaton-credentials.txt

The file (mode 0600 root:root) holds OPERATON_ADMIN_USERNAME (admin) and OPERATON_ADMIN_PASSWORD. This is the account you use to sign in to the web applications and the REST API. The file also holds the web app, Cockpit and REST URLs for this instance.

None of these values ship in the image. Every value is unique to this instance, so no two instances share a credential and there is no default login to change.

Verify the security model

The health endpoint is public, but the REST API and the web applications reject every request without the per-instance administrator credential. Confirm three things. The health endpoint is up. An unauthenticated REST request is rejected with 401. The per-instance administrator credential authenticates a real call and returns the engine:

ADMIN_PW=$(sudo grep '^OPERATON_ADMIN_PASSWORD=' /etc/operaton/operaton.env | cut -d= -f2-)
curl -s -o /dev/null -w 'health (public): %{http_code}\n' http://localhost/healthz
curl -s -o /dev/null -w 'REST user (no auth): %{http_code}\n' http://localhost/engine-rest/user
curl -s -o /dev/null -w 'REST user (admin): %{http_code}\n' -u "admin:$ADMIN_PW" http://localhost/engine-rest/user
curl -s -u "admin:$ADMIN_PW" http://localhost/engine-rest/engine

The health endpoint returns 200 with no secret. The unauthenticated REST call is rejected with 401, because Operaton Run authentication is turned on. The same call with the per-instance administrator credential returns 200.

The final call returns the default engine as JSON ([{"name":"default"}]), which proves the engine is live and the credential works. This is the security model: the per-instance administrator credential gates the REST API and the web apps, and the built-in demo/demo account does not exist.

The image also bundles a script at /usr/local/sbin/operaton-roundtrip.sh that proves the whole model plus a real BPMN round trip. It deploys a minimal process, starts an instance, reads it back from history, and confirms that demo/demo and admin/admin are rejected. The build and smoke tests run it to prove the credential works end to end.

The script deliberately makes rejected login attempts, and Operaton briefly delays logins after a failed attempt. Run it on its own, rather than immediately before an authenticated call.

Open the web applications and sign in

Browse to http://<instance-public-ip>/ to reach the Operaton welcome page. Sign in with the username admin and the OPERATON_ADMIN_PASSWORD from Step 5.

After you sign in, the welcome page links the three web applications: Cockpit, Tasklist and Admin. It also shows your profile and group membership. The administrator belongs to the operaton BPM Administrators group.

Monitor processes in Cockpit

Open Cockpit to monitor the engine. The dashboard shows running process instances, open incidents and open human tasks. It also counts the deployed process, decision and case definitions and deployments.

Because the image runs on a durable PostgreSQL database, everything you deploy and every instance you run survives restarts.

Manage users and authorizations in Admin

Open Admin to manage users, groups, tenants and authorizations. The image ships a single hardened administrator account and no demo users. From here, you can create additional users, place them in groups, and grant fine-grained authorizations over engine resources.

Deploy and start a process from the REST API

The REST API backs every feature of the engine. You can call it directly with the per-instance administrator credential over HTTP Basic authentication. Deploy a minimal BPMN process, start an instance of it, and then list the definitions, all through nginx on port 80:

ADMIN_PW=$(sudo grep '^OPERATON_ADMIN_PASSWORD=' /etc/operaton/operaton.env | cut -d= -f2-)
cat > /tmp/hello.bpmn <<'BPMN' <?xml version="1.0" encoding="UTF-8"?> <bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:operaton="http://operaton.org/schema/1.0/bpmn" targetNamespace="http://example.com/bpmn"> <bpmn:process id="helloWorld" name="Hello World" isExecutable="true" operaton:historyTimeToLive="P30D"> <bpmn:startEvent id="start"><bpmn:outgoing>f</bpmn:outgoing></bpmn:startEvent> <bpmn:endEvent id="end"><bpmn:incoming>f</bpmn:incoming></bpmn:endEvent> <bpmn:sequenceFlow id="f" sourceRef="start" targetRef="end"/> </bpmn:process> </bpmn:definitions> BPMN curl -s -u "admin:$ADMIN_PW" -F 'deployment-name=hello' -F 'data=@/tmp/hello.bpmn' \
  http://localhost/engine-rest/deployment/create -o /dev/null -w 'deploy: %{http_code}\n' curl -s -u "admin:$ADMIN_PW" -H 'Content-Type: application/json' -X POST \
  -d '{"businessKey":"demo-1"}' \
  http://localhost/engine-rest/process-definition/key/helloWorld/start -o /dev/null -w 'start: %{http_code}\n' curl -s -u "admin:$ADMIN_PW" http://localhost/engine-rest/process-definition?key=helloWorld

The deploy and start calls each return 200, and the final call lists the helloWorld process definition you just deployed.

From your own machine, call the same endpoints against http://<instance-public-ip>/engine-rest/... with the administrator credential. The full REST API is documented in the Operaton user documentation.

Server components

Engine and web apps: Operaton Run 2.1.2 (Apache-2.0, pinned by image digest).
Database: PostgreSQL 16 (bundled, durable state, pinned by image digest).
Web applications: Cockpit (monitoring), Tasklist (human tasks) and Admin (users).
Front door: nginx on :80, proxying the engine on 127.0.0.1:8080.
Health endpoint: http://<instance-ip>/healthz (public, no secret).
REST API: http://<instance-ip>/engine-rest/ (HTTP Basic auth, user admin).
Orchestration: Docker Compose under operaton.service.
Admin account: a random per-instance password, generated on first boot into /root/operaton-credentials.txt.
Operating system: Ubuntu 24.04 LTS (patched at build).
Licence: Apache-2.0 (Operaton).

Managing the service

sudo systemctl status operaton --no-pager | head -12 sudo docker compose -f /etc/operaton/compose.yaml logs --tail 40 operaton

Restart the whole stack with sudo systemctl restart operaton. Follow the engine logs live with sudo docker compose -f /etc/operaton/compose.yaml logs -f operaton.

Configuration lives in three files:

/etc/operaton/operaton.env holds the per-instance secrets.
/etc/operaton/default.yml holds the engine configuration.
/etc/operaton/compose.yaml is the Compose file.

After you change configuration, restart the service to apply it.

Use your own domain and HTTPS (production)

The image serves the web applications and REST API over plain HTTP on port 80, which is convenient behind a load balancer or private network. For production, terminate TLS in front of the instance so credentials travel encrypted:

Front the instance with an Application Load Balancer that uses an AWS Certificate Manager certificate, or with a CloudFront distribution, and forward to nginx on port 80.
Or install your own certificate. Add a TLS server block to /etc/nginx/sites-available/operaton that references your certificate and key, open 443/tcp on the security group, and run sudo systemctl reload nginx.
Point a DNS name you control at the instance. Operaton derives request URLs from the Host header, so no configuration change is needed. Use a stable Elastic IP or DNS name.

Security recommendations

Restrict the security group. Allow TCP 80 (and 22 for admin) only from the networks that use the engine.
Terminate TLS in front of the app (Step 13), so the administrator password and REST credentials are encrypted in transit.
Rotate the generated administrator password. Sign in to the Admin web application and change it under Users, then admin, then Account. Keep /root/operaton-credentials.txt in sync.
Keep the engine and database private. The engine is bound to loopback and PostgreSQL runs inside the Compose network. Keep them that way, and never expose those ports directly.
Enable a password policy. Once you manage your own users, enable Operaton's password policy in /etc/operaton/default.yml (operaton.bpm.generic-properties.properties.enable-password-policy: true) and restart the service.
Keep the OS patched. Unattended security upgrades remain enabled on the running instance.

Support and Licensing

Operaton is free, open-source software under the Apache License 2.0, shipped unmodified. SecureAnyCloud produces this image and is not affiliated with, endorsed by, or sponsored by the Operaton project or Camunda. The charges for this listing cover the SecureAnyCloud image and 24/7 support, not the software itself.

SecureAnyCloud provides 24/7 technical support by email and live chat, with a one-hour average response for critical issues. Our engineers help with deployment, TLS termination, database backups, user management, external database configuration and scaling.

Deploy on AWS

Subscribe to Operaton by SecureAnyCloud on the AWS Marketplace, launch the AMI as described above, read the per-instance administrator credential from /root/operaton-credentials.txt, and sign in to the web applications on port 80. Email sales@secureanycloud.com for help at any stage.

Deploy on AWS

Launch Operaton BPMN Workflow and DMN Decision Engine with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on AWS