Apache Artemis 2.57.0 on AWS User Guide
Overview
This guide covers launching and using the Apache Artemis 2.57.0 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg streaming and messaging listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.
Apache Artemis (formerly Apache ActiveMQ Artemis) is a high-performance, multi-protocol message broker. Applications talk to it over its native CORE protocol (the Jakarta and Java Messaging Service clients), AMQP 1.0 (clients for Python, .NET, JavaScript, Go and more) and OpenWire (existing ActiveMQ "Classic" clients), with queues, publish-subscribe topics, durable subscriptions, message groups, scheduled delivery, dead letter and expiry handling, and a persistent journal.
What the cloudimg image adds:
- No default login. The admin password is generated on your instance at first boot. It is stored in the broker's users file only as a salted PBKDF2 hash, and in plain form only in
/root/artemis-credentials.txt(root only). The image ships with no user at all. - Login required on every protocol. Security is switched on and there is no guest or anonymous access: a connection without credentials or with a wrong password is refused, and so are Artemis's well-known default cluster credentials. Clustering and server discovery are switched off on this single broker.
- One TLS port for clients. The broker's only listener is TLS on port 61617 for CORE, AMQP 1.0 and OpenWire, using a certificate generated on your instance (TLS 1.2 and 1.3). There is no plaintext listener, and the MQTT, STOMP and HornetQ listeners of a default installation are not configured.
- Web console over HTTPS only. The Artemis web console (Hawtio and the Jolokia management API) listens on
127.0.0.1:8161. nginx serves it on port 443 with the same per-instance certificate, port 80 redirects to HTTPS, and requests for host names the instance does not serve are dropped. A request carrying another site'sOriginis refused, so is every WebSocket upgrade and the console's proxy feature, and the console login is rate limited per client address. - Fail closed. The broker starts only after the boot service has created your admin user and certificate. Before every start a configuration check refuses to run it without a hashed admin user, with a guest login module, with a plaintext listener on a public address, with clustering, with the console on a public address or with an open management API.
- Hardened defaults. The broker, nginx and the boot service are blocked from the instance metadata service (bridges, federation and broker connections reach addresses an administrator configures, so a mistake or a malicious setting can never reach the instance's credentials), the AMI requires IMDSv2, nginx hands the console the real client address and the configured host name (never values a client sends), and the broker runs under systemd sandboxing as an unprivileged user.
- Fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on.
What is on the image: Apache Artemis 2.57.0 (the official Apache binary release, verified against its published SHA-512 checksum and the Apache release signature), OpenJDK 21 and nginx 1.24 (both from Ubuntu 24.04), cloud-init and the AWS Systems Manager agent.
Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites
- An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet with a route to the internet (or a private route you use for management).
- A security group that allows TCP 22 (SSH) from your admin network, TCP 61617 (the broker) from the networks your applications run in, and TCP 443 (the web console) from your admin network, plus TCP 80 if you want plain HTTP requests redirected to HTTPS. Never open 8161: it listens on the loopback address only.
Step 1: Launch the instance
In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Apache Artemis 2.57.0 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large, your key pair and a security group as above. The broker keeps its message journal on the root volume: give the instance a root volume sized for the messages you expect to hold (Step 13).
With the AWS CLI (replace the values in angle brackets):
aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
--instance-type m5.large --key-name <your-key-pair> \
--security-group-ids <your-security-group> --subnet-id <your-subnet> \
--metadata-options HttpTokens=required,HttpEndpoint=enabled \
--block-device-mappings 'DeviceName=/dev/sda1,Ebs={VolumeSize=30,VolumeType=gp3}' \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=artemis}]'
First boot takes about a minute after the instance is running: the boot service creates the admin user and the certificate, then the broker and nginx start.
Step 2: Connect to your instance
| Version | SSH user |
|---|---|
| Apache Artemis 2.57.0 on Ubuntu 24.04 | ubuntu |
ssh -i <your-key.pem> ubuntu@<public-ip>
Step 3: Check the services
systemctl is-active artemis-firstboot artemis nginx
sudo test -f /var/lib/cloudimg/artemis-firstboot.done && echo FIRSTBOOT_DONE
All three units are active and the first boot marker is present:
active
active
active
FIRSTBOOT_DONE
Only SSH, nginx and the broker's TLS port listen on network interfaces; the web console listens on the loopback address:
sudo ss -lntp | awk 'NR>1 {print $4, $6}' | grep -v '127.0.0.5' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g' | sort
*:61617 users:(("java"))
0.0.0.0:22 users:(("sshd"),("systemd"))
0.0.0.0:443 users:(("nginx"),("nginx"),("nginx"))
0.0.0.0:80 users:(("nginx"),("nginx"),("nginx"))
[::]:22 users:(("sshd"),("systemd"))
[::]:443 users:(("nginx"),("nginx"),("nginx"))
[::]:80 users:(("nginx"),("nginx"),("nginx"))
[::ffff:127.0.0.1]:8161 users:(("java"))
Step 4: Get your URLs and admin password
sudo cat /root/artemis-credentials.txt
The file is readable by root only:
# Apache Artemis 2.57.0 on Ubuntu 24.04 - generated on first boot by artemis-firstboot.service.
# The admin password below is unique to this instance; none was baked into the image. Keep this file secret.
# Web console: open ARTEMIS_CONSOLE_URL and log in as ARTEMIS_ADMIN_USER.
# Messaging clients (CORE, AMQP 1.0, OpenWire) connect over TLS to port 61617 and trust ARTEMIS_TLS_CERT
# (a self-signed certificate minted on this instance; replace it with your own, see the user guide).
# Change the served name: sudo artemis-set-hostname <dns-name>
ARTEMIS_CONSOLE_URL=https://<public-ip>/console/
ARTEMIS_ADMIN_USER=admin
ARTEMIS_ADMIN_PASSWORD=<ARTEMIS_ADMIN_PASSWORD>
ARTEMIS_BROKER_HOST=<public-ip>
ARTEMIS_CORE_URL=tcp://<public-ip>:61617?sslEnabled=true;trustStoreType=PEM;trustStorePath=/etc/artemis/broker.crt
ARTEMIS_AMQP_URL=amqps://<public-ip>:61617
ARTEMIS_OPENWIRE_URL=ssl://<public-ip>:61617
ARTEMIS_TLS_CERT=/etc/artemis/broker.crt
# Re-verify the appliance: sudo artemis-selfcheck
# User guide: https://www.cloudimg.co.uk/guides/apache-artemis-2-57-0-on-ubuntu-24-04-aws/
The host is the instance's public IP address from the EC2 instance metadata (the private address when the instance has no public one). The certificate also names the public DNS name and the private IP address and DNS name, so clients inside the VPC can connect by the private address. If you stop and start the instance without an Elastic IP, the boot service picks up the new address and issues a new certificate for it. To serve the broker under your own DNS name, see Step 9.
Step 5: The web console
Open https://<public-ip>/console/ in a browser. The certificate is self signed, so the browser asks you to accept it the first time (or install your own, Step 9). Log in as admin with the password from the credentials file.

The Status tab shows the broker version, uptime, memory and disk use, and the acceptor:

Queues lists every queue with its routing type and message count; select a queue to browse, send, move or delete messages. Addresses shows the addresses queues are bound to, and Connections, Sessions, Producers and Consumers show live clients:

Step 6: Send and receive messages from the instance
The Artemis command line client is installed in /opt/artemis/current/bin. Send ten messages to a queue named orders over TLS. The command connects without a password first, then asks for it: paste the admin password at the Type the password for a retry prompt (it is not echoed):
/opt/artemis/current/bin/artemis producer --user admin --destination queue://orders --message-count 10 \
--url 'tcp://127.0.0.1:61617?sslEnabled=true;trustStoreType=PEM;trustStorePath=/etc/artemis/broker.crt'
Connection brokerURL = tcp://127.0.0.1:61617?sslEnabled=true;trustStoreType=PEM;trustStorePath=/etc/artemis/broker.crt
Connection failed::AMQ229031: Unable to validate user from 127.0.0.1:<port>. Username: admin; SSL certificate subject DN: unavailable
--password: is mandatory with this configuration:
Type the password for a retry
Producer ActiveMQQueue[orders], thread=0 Produced: 10 messages
Receive them again:
/opt/artemis/current/bin/artemis consumer --user admin --destination queue://orders --message-count 10 \
--url 'tcp://127.0.0.1:61617?sslEnabled=true;trustStoreType=PEM;trustStorePath=/etc/artemis/broker.crt'
Consumer ActiveMQQueue[orders], thread=0 Consumed: 10 messages
The broker creates a queue the first time a client uses it (auto-create-queues), so orders now appears in the console. Avoid --password on the command line: other users on the instance could see it in the process list.
Step 7: Connect your applications
Clients outside the instance connect to <public-ip>:61617 (or the private address inside the VPC) over TLS and must trust the instance's certificate. Copy it to the client machine:
scp -i <your-key.pem> ubuntu@<public-ip>:/etc/artemis/broker.crt artemis-broker.crt
Connection settings for the three protocols (user admin, password from the credentials file, or a user you create in Step 10):
| Protocol | Clients | URL |
|---|---|---|
| CORE | Artemis JMS / Jakarta Messaging client, artemis CLI |
tcp://<host>:61617?sslEnabled=true;trustStoreType=PEM;trustStorePath=artemis-broker.crt |
| AMQP 1.0 | Qpid JMS, Qpid Proton (Python, C, .NET), rhea (JavaScript), go-amqp | amqps://<host>:61617 with the certificate as the trusted CA |
| OpenWire | ActiveMQ "Classic" 5.x clients | ssl://<host>:61617 with the certificate in the client's trust store |
A Java client using the Artemis JMS client library:
ConnectionFactory cf = new ActiveMQConnectionFactory(
"tcp://<host>:61617?sslEnabled=true;verifyHost=true;trustStoreType=PEM;trustStorePath=/path/to/artemis-broker.crt");
try (Connection c = cf.createConnection("admin", System.getenv("ARTEMIS_PASSWORD"))) { ... }
A Python client using Qpid Proton (pip install python-qpid-proton):
from proton import SSLDomain
from proton.utils import BlockingConnection
ssl = SSLDomain(SSLDomain.MODE_CLIENT); ssl.set_trusted_ca_db("artemis-broker.crt"); ssl.set_peer_authentication(SSLDomain.VERIFY_PEER_NAME)
conn = BlockingConnection("amqps://<host>:61617", ssl_domain=ssl, user="admin", password=os.environ["ARTEMIS_PASSWORD"], allowed_mechs="PLAIN")
Java clients that use a PKCS12 trust store instead of PEM can build one from the certificate with keytool -importcert -file artemis-broker.crt -keystore artemis-trust.p12 -storetype PKCS12. If clients connect by a DNS name, set that name first (Step 9) so the certificate matches it.
Step 8: The management API (Jolokia)
Everything the console does goes through the Jolokia management API at https://<host>/console/jolokia/. Scripts can call it with HTTP Basic authentication; the request must carry an Origin header naming this instance (https://<host>), because Jolokia refuses requests from any other origin. Keep the password out of the command line by putting it in a curl configuration file readable only by you:
umask 077; sudo sed -n 's/^ARTEMIS_ADMIN_PASSWORD=//p' /root/artemis-credentials.txt | { read -r P; printf 'user = "admin:%s"\n' "$P"; } > ~/.artemis-curl
H=$(sudo sed -n 's/^ARTEMIS_BROKER_HOST=//p' /root/artemis-credentials.txt)
curl -sk -K ~/.artemis-curl -H "Origin: https://$H" --connect-to "$H:443:127.0.0.1:443" \
"https://$H/console/jolokia/read/org.apache.activemq.artemis:broker=%22artemis%22/Version"; echo
rm -f ~/.artemis-curl
{"request":{"mbean":"org.apache.activemq.artemis:broker=\"artemis\"","attribute":"Version","type":"read"},"value":"2.57.0","timestamp":<timestamp>,"status":200}
nginx limits requests that carry an Authorization header to 30 per minute per client address (bursts of 30 are allowed), so a script cannot be used to guess passwords. For monitoring, prefer a dedicated user (Step 10).
Step 9: Your own DNS name and certificate
Point a DNS record at the instance, then tell Artemis to serve that name. This updates nginx, issues a new self signed certificate that names it (used by both the console and the broker port), accepts https://<name> as an allowed origin for the console and the management API, updates the URLs in the credentials file and restarts the broker:
sudo artemis-set-hostname mq.example.com
The name is saved in /etc/cloudimg/artemis-hostname and survives reboots. Clients then trust the new /etc/artemis/broker.crt.
To use a certificate from your own CA or from Let's Encrypt for both the console and the broker, install it in these four places, then restart the broker and reload nginx:
sudo install -o root -g root -m 0600 server.key /etc/nginx/ssl/artemis.key
sudo install -o root -g root -m 0644 fullchain.crt /etc/nginx/ssl/artemis.crt
cat server.key fullchain.crt | sudo install -o root -g artemis -m 0640 /dev/stdin /etc/artemis/tls/broker.pem
sudo install -o root -g root -m 0644 fullchain.crt /etc/artemis/broker.crt
sudo systemctl restart artemis && sudo systemctl reload nginx
/etc/artemis/tls/broker.pem holds the private key followed by the certificate chain (the broker reads it as a PEM key store). If you later run artemis-set-hostname again, it replaces these files with a new self signed certificate.
Step 10: Users and passwords
Users live in /var/lib/artemis/etc/artemis-users.properties and their roles in artemis-roles.properties. Passwords are stored as Artemis PBKDF2 hashes, ENC(1024:<salt>:<hash>), never in plain text. The amq role holds every messaging and management permission. The broker re-reads both files automatically, so no restart is needed.
To add a user, run the block below. It reads the new password without echoing it, computes the hash (the password reaches Python on standard input, never the command line) and appends the user with the amq role. For narrower permissions, add a role of your own to the security-settings in broker.xml (see the Artemis security documentation):
read -rp 'New user name: ' U; read -rsp "Password for $U: " P; echo
printf '%s' "$P" | sudo python3 -I -c '
import hashlib, os, sys
u, p = sys.argv[1], sys.stdin.read()
s = os.urandom(32)
h = hashlib.pbkdf2_hmac("sha1", p.encode(), s, 1024, 64)
open("/var/lib/artemis/etc/artemis-users.properties", "a").write("%s = ENC(1024:%s:%s)\n" % (u, s.hex().upper(), h.hex().upper()))
r = "/var/lib/artemis/etc/artemis-roles.properties"
t = open(r).read().splitlines()
t = [l + "," + u if l.startswith("amq = ") else l for l in t]
open(r, "w").write("\n".join(t) + "\n")
' "$U"; unset P
To change the admin password, replace its hash and the credentials file the same way:
read -rsp 'New admin password: ' P; echo
printf '%s' "$P" | sudo python3 -I -c '
import hashlib, os, re, sys
p = sys.stdin.read(); s = os.urandom(32)
h = hashlib.pbkdf2_hmac("sha1", p.encode(), s, 1024, 64)
f = "/var/lib/artemis/etc/artemis-users.properties"
t = re.sub(r"(?m)^admin = ENC\(.*\)$", lambda m: "admin = ENC(1024:%s:%s)" % (s.hex().upper(), h.hex().upper()), open(f).read())
open(f, "w").write(t)
c = "/root/artemis-credentials.txt"
open(c, "w").write(re.sub(r"(?m)^ARTEMIS_ADMIN_PASSWORD=.*$", lambda m: "ARTEMIS_ADMIN_PASSWORD=" + p, open(c).read()))
'; unset P
The configuration check refuses to start the broker if any user has a plain text password, so always store the hash.
Step 11: Security checks
artemis-selfcheck re-proves the whole appliance with this instance's credentials. For each protocol it shows that an anonymous connection and a wrong password are refused with the broker's own error, and that the admin login sends and receives a message over TLS. It also checks that the default cluster credentials and plaintext clients are refused, then covers the console login, the management API, the redirect, refusal of other host names, cross-origin requests and WebSocket upgrades, the loopback-only console and the metadata block inside every service:
sudo artemis-selfcheck
Apache Artemis appliance self-check (broker <public-ip>:61617, console https://<public-ip>/console/)
[ok] CORE anonymous connection refused (JMSSecurityException, AMQ229031)
[ok] CORE wrong password refused (JMSSecurityException, AMQ229031)
[ok] CORE over TLS: admin login with this instance's password sent and received a message on cloudimg.selfcheck.core
[ok] AMQP anonymous connection refused (JMSSecurityException, AMQ229031 amqp:unauthorized-access)
[ok] AMQP wrong password refused (JMSSecuritySaslException, SASL PLAIN rejected)
[ok] AMQP over TLS: admin login with this instance's password sent and received a message on cloudimg.selfcheck.amqp
[ok] OPENWIRE anonymous connection refused (JMSSecurityException, AMQ229031 (user name or password is invalid))
[ok] OPENWIRE wrong password refused (JMSSecurityException, AMQ229031 (user name or password is invalid))
[ok] OPENWIRE over TLS: admin login with this instance's password sent and received a message on cloudimg.selfcheck.openwire
[ok] CORE default cluster credentials (ACTIVEMQ.CLUSTER.ADMIN.USER / CHANGE ME!!) refused (JMSSecurityException, AMQ229031)
[ok] a plaintext (non-TLS) CORE client cannot use port 61617 (JMSException)
[ok] port 61617 presents this instance's certificate (/etc/artemis/broker.crt); TLS 1.1 refused
[ok] HTTPS console page -> 200
[ok] Jolokia without a login -> 403, with a wrong password -> 403; wrong console login -> 403
[ok] console login with the per-instance password -> Secure session; Jolokia reports broker version 2.57.0
[ok] Jolokia with HTTP Basic + this instance's origin -> 200; without an Origin -> refused by Jolokia's strict check
[ok] the console's same-origin Jolokia GET (Referer, no Origin) -> 200; a foreign Referer -> refused by Jolokia
[ok] port 80 -> 301 https://<public-ip>/; unknown Host -> 444; CONNECT refused; cross-origin login/Jolokia -> 403; WebSocket -> 403; Hawtio proxy -> 404
[ok] console 8161 refuses the private address; no plaintext CORE/AMQP/MQTT/STOMP/HornetQ listener (61616/5672/1883/61613/5445)
[ok] instance metadata refused inside the artemis and nginx cgroups (loopback control 200)
SELFCHECK OK - TLS messaging (CORE, AMQP, OpenWire) with the per-instance login, console over HTTPS, origin guard, loopback-only console, metadata block verified.
The self-check creates three small queues named cloudimg.selfcheck.* and leaves them empty. The metadata block is a systemd IPAddressDeny rule on each service; you can see it in effect:
for u in artemis nginx artemis-firstboot; do printf '%s: ' $u; systemctl show -p IPAddressDeny --value $u.service; done
artemis: fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32
nginx: fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32
artemis-firstboot: fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32
Because of this block, broker plugins cannot pick up the instance's IAM role credentials. Bridges, federation and broker connections to other hosts work normally.
Step 12: Adding protocols or listeners
The only listener is the tls acceptor in /var/lib/artemis/etc/broker.xml. To also accept MQTT or STOMP clients, add them to its protocols= list (for example protocols=CORE,AMQP,OPENWIRE,MQTT), keep sslEnabled=true, and restart the broker with sudo systemctl restart artemis. MQTT and STOMP clients then connect over TLS to port 61617 as well. The configuration check refuses to start the broker with a listener on a public address that does not use TLS. A plaintext listener for local applications on the same instance is allowed on 127.0.0.1 only, for example <acceptor name="local">tcp://127.0.0.1:61616?protocols=CORE,AMQP</acceptor>.
Step 13: Versions, provenance and file locations
sed -n '1,7p' /usr/share/doc/apache-artemis/BUILD-PROVENANCE.txt
java -version 2>&1 | sed -n 1p
Apache Artemis 2.57.0 (formerly Apache ActiveMQ Artemis) - official ASF binary release (not rebuilt)
source https://downloads.apache.org/artemis/artemis/2.57.0/apache-artemis-2.57.0-bin.tar.gz
sha512 47d2193b4707bde8c856ee0f7ee623e87722559b8503aaef6ee015496499774a8c9b9492933cc0a52873e95dce73ff825222422996d2a8768a4936b015415e8c
signature apache-artemis-2.57.0-bin.tar.gz.asc, VALIDSIG 28417C95E8906D108392822354A43F3254868410 (ASF KEYS)
licence Apache License 2.0 (LICENSE sha256 7f0599bdd57251da388bf4556e0a05ac88c5129c8578daafbace5b5360233cf1; bundled third-party notices in LICENSE/NOTICE)
runtime OpenJDK 21 (Ubuntu main, /usr/lib/jvm/java-21-openjdk-amd64)
netty-handler 4.1.137.Final (CVE-2026-75595 fixed in 4.1.137)
openjdk version "21.0.12.1" 2026-08-18
| Path | What it is |
|---|---|
/var/lib/artemis/etc/broker.xml |
broker settings: acceptor, addresses, queues, security settings |
/var/lib/artemis/etc/artemis-users.properties, artemis-roles.properties |
users (hashed passwords) and roles |
/var/lib/artemis/data |
the message journal, bindings, paging and large messages |
/var/lib/artemis/log/artemis.log |
the broker log (also journalctl -u artemis) |
/root/artemis-credentials.txt |
URLs and admin password (root only) |
/etc/artemis/broker.crt, /etc/artemis/tls/broker.pem |
the certificate clients trust; the broker's key and certificate |
/etc/nginx/sites-available/cloudimg-artemis |
the HTTPS front door of the console; certificate and key in /etc/nginx/ssl/ |
/opt/artemis/current |
the Artemis distribution and command line client |
/usr/share/doc/apache-artemis/ |
LICENSE, NOTICE and BUILD-PROVENANCE.txt |
Step 14: Backup and maintenance
- Back up
/var/lib/artemis/etc(configuration and users),/etc/artemis,/etc/cloudimgand/etc/nginx/ssl. To back up messages, stop the broker and copy/var/lib/artemis/data, or use EBS snapshots of the root volume. - The journal lives on the root volume. The broker blocks producers when the disk is 90 % full (
max-disk-usage), so size the root volume for your backlog when you launch (Step 1), or grow it later with an EBS volume modification andsudo growpart /dev/nvme0n1 1 && sudo resize2fs /dev/nvme0n1p1. - The broker runs with a Java heap of up to 2 GB (
-Xmx2Gin/var/lib/artemis/etc/artemis.profile). An m5.large is comfortable; for large backlogs or many connections raise the heap and use a larger instance. - Ubuntu security updates install automatically (unattended-upgrades), including the OpenJDK runtime. Artemis itself lives in
/opt/artemis; to upgrade, launch the newer version from the listing and move your configuration and data across.
Step 15: Security recommendations
- Limit TCP 61617 in the security group to the networks your applications run in, TCP 443 to your admin network and TCP 22 to your admin network. The console can read, move and delete messages; treat it as an administrative console, ideally reachable over a VPN or a private load balancer only.
- Give each application its own user with only the permissions it needs, and change the admin password if you share the credentials file (Step 10).
- Serve the broker under your own DNS name with a certificate from a trusted CA (Step 9), and have clients verify the host name.
- Keep TLS on every listener that is reachable from the network, and keep the console on
127.0.0.1.
Support and licensing
cloudimg provides 24/7 technical support for this image by email and live chat: support@cloudimg.co.uk. Apache Artemis is licensed under the Apache License 2.0 (its LICENSE and NOTICE files, including the licences of the components it bundles, are on the instance in /usr/share/doc/apache-artemis), and OpenJDK under the GNU General Public License version 2 with the Classpath Exception. Apache Artemis, ActiveMQ, Apache and the Apache feather logo are trademarks of the Apache Software Foundation; cloudimg is not affiliated with or endorsed by the Apache Software Foundation.