Petals ESB

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting size. A single Petals node is one JVM with a 1 GiB heap.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network only. No inbound application ports are needed, because you reach the bus in-process, over loopback or over an SSH tunnel.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Petals ESB by SecureAnyCloud, and select Create.

On the Basics tab, 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) only.

Select Review + create, and then select Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:petals-esb-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name petals-esb \
  --image sac1647283583153:petals-esb-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

Step 3 - Connect to your VM

Connect over SSH as the azureuser administrator account:

ssh azureuser@<vm-public-ip>

On first boot, petals-firstboot.service rotates the two shipped default secrets to unique per-VM values. It then starts petals-esb.service, which recovers the pre-deployed sample. Allow a minute for a fresh VM to finish.

Step 4 - Confirm the node is installed and healthy

Check the Java version, the Petals container version, the service state and the SOAP component:

. /etc/petals/petals.env "${JAVA_HOME}/bin/java" -version cat /opt/petals/system-extensions/petals-esb-container.version systemctl is-active petals-esb.service printf 'GET /petals/services/ : HTTP %s\n' "$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8084/petals/services/)"

The output shows OpenJDK 17, the Petals container version 5.4.0, an active service, and the SOAP component answering with 200:

openjdk version "17.0.20" 2026-07-21 17.0.20+8 ... 5.4.0 active GET /petals/services/ : HTTP 200

Step 5 - Route a real message through the bus

The image deploys a working sample: the Clock service engine, exposed as a SOAP web service by the SOAP binding component. Send a time request to the endpoint. The message routes over HTTP into the binding component, across the bus to the Clock service engine, and back with the current time. This is a genuine end-to-end trip through the ESB:

curl -s -X POST http://127.0.0.1:8084/petals/services/ClockHttpEndpoint \
  -H 'Content-Type: text/xml;charset=UTF-8' -H 'SOAPAction: ""' \
  --data '<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:pet="http://petals.ow2.org"><soapenv:Body><pet:time/></soapenv:Body></soapenv:Envelope>'

<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><timeResponse xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><timeReturn xsi:type="xsd:string">08/13/2026 08:30:13</timeReturn></timeResponse></soapenv:Body></soapenv:Envelope>

The Clock service engine produced the <timeReturn> value in the response and carried it back across the bus, which proves that the container is routing messages. A bundled wrapper script, /opt/petals/bin/clock-roundtrip.sh, prints CLOCK_ROUNDTRIP_OK time=... on success.

Step 6 - Retrieve your per-VM secrets

The image ships no shared credential. On first boot, both upstream defaults (the topology passphrase and the JMX admin password, each petals out of the box) are rotated to unique per-VM secrets and written to a root-only file. Read the file with sudo:

sudo cat /stage/scripts/petals-credentials.log

The file contains PETALS_JMX_USER (petals), PETALS_JMX_PASSWORD and PETALS_TOPOLOGY_PASSPHRASE, each unique to this VM. In the next step, <PETALS_JMX_PASSWORD> stands for the JMX password value from this file.

Step 7 - Operate the container with the Petals CLI

The petals-cli tool connects to the running container over JMX (loopback, port 7700) and administers it. You can list and manage components and service assemblies, read the topology and print the container version. Authenticate with the per-VM JMX password:

sudo /opt/petals-cli/bin/petals-cli.sh \
  -h 127.0.0.1 -n 7700 -u petals -p '<PETALS_JMX_PASSWORD>' \
  -c -- version

Petals ESB µKernel 4.4.0 Petals Standalone Shared Memory 4.4.0 Petals ESB Autoloader 1.3.0 OpenJDK Runtime Environment 17.0.20+8 Eclipse Adoptium Linux 6.17.0-1022-azure amd64

The default password petals is rejected, and only your per-VM secret authenticates. Run petals-cli.sh -C for an interactive console. The help command lists the available commands, such as show, stop, list, monitoring and topology.

Step 8 - Verify the secure-by-default configuration

The SOAP endpoint is bound to loopback, both shipped default secrets are rotated per VM, and the host firewall keeps every Petals port off the network. Confirm that the SOAP endpoint answers on localhost but is refused on the VM's network interface, that the credentials file is root-only, and that ufw allows only SSH:

IP=$(hostname -I | awk '{print $1}') stat -c 'file: %n perms: %a owner: %U:%G' /stage/scripts/petals-credentials.log echo -n "localhost :8084 = HTTP "; curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8084/petals/services/ echo -n "NIC $IP :8084 = "; curl -s -o /dev/null -w '%{http_code}\n' --max-time 4 http://$IP:8084/petals/services/ || echo 'connection refused'
sudo ufw status verbose | grep -E 'Status:|Default:|22/tcp'

file: /stage/scripts/petals-credentials.log perms: 600 owner: root:root localhost :8084 = HTTP 200 NIC 10.0.0.18 :8084 = connection refused Status: active Default: deny (incoming), allow (outgoing), disabled (routed) 22/tcp ALLOW IN Anywhere
# SSH

The SOAP endpoint is reachable only on loopback. By Petals design, the JMX (7700) and inter-container transport (7800) ports bind all interfaces, but the default-deny firewall closes them to the network. To reach the SOAP endpoint from your workstation, open an SSH tunnel with ssh -L 8084:127.0.0.1:8084 azureuser@<vm-public-ip>.

Step 9 - Deploy your own components and service assemblies

Petals installs JBI artifacts when you drop them into the container's autoloader directory. Copy a component or service-assembly zip into the install directory as the petals user, and the container installs and starts it automatically:

sudo install -o petals -g petals -m 0644 my-service-assembly.zip \
  /opt/petals/data/install/
sudo journalctl -u petals-esb -f
# watch it deploy

Petals publishes a rich component catalog on Maven Central (org.ow2.petals). It includes SOAP, REST, JMS, file transfer, mail and database binding components, plus the Flowable BPMN service engine and more, so you can wire external protocols to your own services.

Build service units against the Petals CDK, package them into a service assembly, and deploy them as shown above. The pre-installed Clock and SOAP sample is a minimal, working reference for the consume-endpoint pattern.

Maintenance

• Configuration. The container settings live in /opt/petals/conf/server.properties (topology passphrase, autoloader, transport tuning) and /opt/petals/conf/topology.xml (JMX port and admin credentials). JVM options are in /opt/petals/conf/env.sh (-Xmx1024m stock). After you edit a file, run sudo systemctl restart petals-esb.
• Heap. The default 1 GiB heap suits Standard_B2s. On larger VMs with heavier integration workloads, raise -Xmx in /opt/petals/conf/env.sh.
• Service control. Use sudo systemctl status petals-esb to check the service and journalctl -u petals-esb to read its logs. The container's own log is /opt/petals/logs/petals.log.
• Secrets. The per-VM topology passphrase and JMX admin password are in /stage/scripts/petals-credentials.log (root-only). To reach JMX from another host, tunnel over SSH, and never expose port 7700 to the network.
• Firewall. By default, ufw allows only SSH inbound. If you expose services, open additional ports deliberately, for example for a SOAP endpoint that you publish behind TLS.
• Security patches. The image keeps unattended-upgrades enabled, so the OS continues to receive security updates automatically.

Support

SecureAnyCloud provides 24/7 expert support for this image. Contact sales@secureanycloud.com.

Petals ESB is open source under the GNU Lesser General Public License (LGPL) 2.1 and is developed by the OW2 community and Linagora. SecureAnyCloud provides this image and is not affiliated with or endorsed by the Petals project, OW2 or Linagora.

Deploy on Azure

Launch Petals ESB 5.4.0 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