Apache Seata Server on Ubuntu 24.04 on Azure User Guide

Overview

Apache Seata is an open source distributed transaction solution for microservices. At its centre is the Seata Server, a Transaction Coordinator (TC) that your services register with so that a single business operation spanning several microservices and databases either commits everywhere or rolls back everywhere. It supports the AT, TCC, SAGA and XA transaction modes. The cloudimg image installs Apache Seata 2.6.0 on OpenJDK 25 at /opt/seata, runs the Transaction Coordinator (seata-server) in standalone file-store mode (self-contained, no external database) on TCP 8091, and runs the bundled Seata NamingServer, which hosts the web console and registry, fronted by an nginx reverse proxy on TCP 80. A unique console password is generated on the first boot of every VM. Backed by 24/7 cloudimg support.

What is included:

• Apache Seata 2.6.0 Transaction Coordinator (seata-server) on OpenJDK 25 at /opt/seata, in standalone file-store mode (no external database)
• The bundled Seata NamingServer, hosting the web console and the registry, bound to loopback 127.0.0.1:8081
• nginx reverse proxy on :80 in front of the web console
• The Transaction Coordinator RPC endpoint on :8091 for your microservice clients (TM/RM) to connect to
• Per-VM console password (SEATA_CONSOLE_PASSWORD) generated at first boot, in a root only file; the upstream default login is disabled
• seata-namingserver.service, seata-server.service and nginx.service as systemd units, enabled and active
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting point; scale up for higher transaction throughput. NSG inbound: allow 22/tcp from your management network, 80/tcp for the web console (front with TLS for public exposure, see Enabling HTTPS), and 8091/tcp for the Transaction Coordinator from the application subnets whose microservices will register with it.

Step 1 — Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Apache Seata by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Then Review + create then Create.

Step 2 — Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name seata \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name seata --port 80 --priority 1010
az vm open-port --resource-group <your-rg> --name seata --port 8091 --priority 1020

Step 3 — Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 — Confirm the services are running

systemctl is-active seata-namingserver.service seata-server.service nginx.service

All three report active. The JVM can take 30–60 seconds to fully start on first boot while it warms up.

ss -tln | grep -E ':80 |:8081 |:8091 '

You should see nginx on :80, the console bound to loopback on 127.0.0.1:8081, and the Transaction Coordinator on :8091:

Step 5 — Retrieve your web console password

A unique console password is generated on the first boot of every VM and written to a root only file. There is no shared or default login.

sudo cat /root/seata-credentials.txt

The file records the console URL, the console user (seata) and the per-VM password:

Step 6 — Sign in to the web console

Browse to http://<vm-public-ip>/ and sign in as seata with the password from Step 5.

After signing in you land on the TransactionInfo view, which lists global transactions coordinated by the server (empty until your applications start running transactions):

Step 7 — Verify the Transaction Coordinator is up

The web console health endpoint is unauthenticated and answers through nginx:

curl -s http://127.0.0.1/naming/v1/health

{"code":"200","message":"success","success":true}

To prove the coordinator itself is up (not merely that the port is open), sign in and open ClusterManager, then click View on the default cluster. The console shows the Transaction Coordinator registered as a healthy member on port 8091:

The same fact is available from the console API. Log in for a token, then query the registered cluster:

PW=$(sudo grep '^SEATA_CONSOLE_PASSWORD=' /root/seata-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -s -H 'Content-Type: application/json' -X POST \
  -d "{\"username\":\"seata\",\"password\":\"<SEATA_CONSOLE_PASSWORD>\"}" \
  http://127.0.0.1/api/v1/auth/login | jq -r .data)
curl -s -H "Authorization: $TOKEN" \
  'http://127.0.0.1/naming/v1/clusters?namespace=public' \
  | jq '.[0].unitData[0].namingInstanceList[0] | {transaction, healthy, role, version}'

{
  "transaction": { "host": "10.0.0.10", "port": 8091 },
  "healthy": true,
  "role": "MEMBER",
  "version": "2.6.0"
}

Step 8 — Connect your microservice clients to the coordinator

Your Seata clients (the Transaction Manager and Resource Managers embedded in your microservices) connect directly to the Transaction Coordinator on TCP 8091. Using the standalone file registry, point each client at the coordinator's address. For a Spring Boot application, set:

seata:
  tx-service-group: default_tx_group
  service:
    vgroup-mapping:
      default_tx_group: default
    grouplist:
      default: <vm-private-ip>:8091
  registry:
    type: file
  config:
    type: file

Open your NSG to allow 8091/tcp from the subnets where those microservices run. As your applications begin coordinating transactions, they appear in the TransactionInfo view, and any held global locks appear under GlobalLockInfo:

Enabling HTTPS

The console is served over plain HTTP on :80 by nginx. For public exposure, put a certificate in front of it. With your own DNS name pointed at the VM:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d seata.example.com

certbot obtains a certificate, rewrites the nginx site to listen on 443 with a redirect from :80, and installs a renewal timer.

Backup and maintenance

The Transaction Coordinator stores its session/lock state under /opt/seata/current/seata-server/sessionStore (standalone file mode). Service logs are under /var/log/seata. To restart the stack after a configuration change:

sudo systemctl restart seata-namingserver.service seata-server.service

The base image keeps receiving unattended security updates. Scale the VM up for higher transaction throughput; the JVM heaps are tuned for the 4 GiB Standard_B2s.

Support

Every cloudimg image is backed by 24/7 support. If you have any questions about this deployment, contact us through cloudimg.co.uk.