Application Infrastructure Azure

Operaton on Ubuntu 24.04 on Azure User Guide

| Product: Operaton on Ubuntu 24.04 LTS on Azure

Overview

Operaton is an open source, community driven workflow and decision automation engine, the continuation of Camunda 7. It executes BPMN 2.0 processes and DMN decision tables through a persistent process engine, and ships three web apps, Cockpit for operating and monitoring, Tasklist for human tasks and Admin for users, groups and authorizations, plus a full REST API. The cloudimg image runs the free and open source Apache-2.0 engine (operaton/operaton, the self contained distribution) the officially supported way as the upstream container, alongside a bundled PostgreSQL for durable state, orchestrated by Docker Compose under systemd and fronted by nginx. Both images are pinned by digest and captured into the VM, so your instance starts in seconds. A unique admin password and a unique database password are generated for each VM on first boot, before the port is reachable, and the image ships with no default demo account and the REST API locked behind authentication, so the engine is secure from the very first request. Backed by 24/7 cloudimg support.

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

The Operaton Cockpit dashboard showing running process instances and human tasks over the bundled PostgreSQL database

What is included:

  • 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, fully patched, with 24/7 cloudimg support

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 cloudimg in the Azure Marketplace, select Get It Now, choose your subscription, resource group and region, and select the recommended Standard_B2s size (or larger for heavier workloads). Allow inbound 22 and 80, then create the VM.

Step 2 - Deploy from the Azure CLI

You can also deploy with the Azure CLI. Replace the image URN with the one shown on the offer page:

az vm create \
  --resource-group my-rg \
  --name operaton \
  --image <publisher>:<offer>:<sku>: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 the systemd services are active and that both containers (the engine and the bundled PostgreSQL) are healthy:

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

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

The Operaton engine and bundled PostgreSQL containers running and healthy under systemd

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, this request 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.

The REST API rejecting no credentials, the default demo account and a weak password with 401, and accepting only the per-VM admin password with 200

Your unique admin password is written to /root/operaton-credentials.txt, readable only by root:

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

It reports 600 root:root. View the notes (which include your admin password, the web app URLs and the REST endpoint) with:

sudo cat /root/operaton-credentials.txt

The per-VM access notes, with the admin and database passwords masked

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.

The Operaton Cockpit login page, gating access to the web apps

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

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

The Cockpit Processes view showing a deployed BPMN process, its diagram and its running instances

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/cloudimg-roundtrip.bpmn. The block below reads your admin password from the notes file (so it never appears on screen), deploys the process and starts an instance, 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/cloudimg-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/cloudimgRoundtrip/start | jq '{id, ended}'

The deploy call returns the new deployment id, and the start call returns the process instance id, proving 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

Starting a BPMN process instance over the authenticated REST API and counting the running instances

Step 8 - Manage users

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

The Admin Users view showing the single per-VM administrator and no default demo accounts

To change the admin password, edit the account in Admin > Users > admin > Account, then 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 (for example Certbot with the nginx plugin), then front the engine on 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 by setting 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 cloudimg. If you need help, contact support through the cloudimg listing on the Azure Marketplace. Operaton is free and open source software under the Apache License 2.0; the cloudimg image adds first boot secret generation, a bundled PostgreSQL, security hardening and 24/7 support.