Infinispan

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Infinispan Data Grid 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). Then select Review + create, and then Create. Open port 11222 afterwards, as shown in the next step.

Accept the image terms once per subscription, then deploy:

az vm image terms accept --urn sac:infinispan-ubuntu-24-04:default:latest
az group create --name infinispan-rg --location eastus
az vm create \
  --resource-group infinispan-rg \
  --name infinispan-vm \
  --image sac1647283583153:infinispan-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
az vm open-port --resource-group infinispan-rg --name infinispan-vm --port 11222 --priority 1010

Connect to your VM over SSH as the administrator user you chose at deployment:

ssh azureuser@<vm-public-ip>

The service is infinispan. systemd starts it only after first boot finishes provisioning your VM, so on a brand-new instance it can take a few seconds longer than the other services to become active.

systemctl is-active infinispan

Expected output:

active

The liveness probe is deliberately open. An Azure load balancer or a monitoring agent calls it, and it returns nothing but a health word:

curl -sk https://localhost:11222/rest/v2/container/health/status

Expected output:

HEALTHY

The runtime is OpenJDK 25, the version that Infinispan 16.2's server modules are compiled for:

java -version 2>&1 | head -1

Expected output:

openjdk version "25.0.4" 2026-07-21

Infinispan multiplexes several protocols onto one port. The REST API, the web console and the binary Hot Rod protocol all arrive on port 11222, and the server picks the protocol for each connection.

sudo ss -Hltn | awk '{print $4}' | sort -u

Expected output:

0.0.0.0:11222 0.0.0.0:22 127.0.0.53%lo:53 127.0.0.54:53 [::]:22

Only 22 and 11222 are reachable from outside the VM. The two 127.0.0.x:53 entries are the local DNS stub resolver.

There are no cluster ports here, and that is deliberate. Infinispan's stock configuration starts a JGroups cluster transport, which binds TCP 7800, TCP 57800 and a UDP multicast discovery socket. This image is a single node, so its configuration declares no transport at all. The server never creates those sockets, instead of creating them and then firewalling them off. The image ships a check that verifies this:

sudo /usr/local/sbin/infinispan-port-check.sh

Expected output:

off-box TCP exactly [22 11222] JGroups 7800/57800/udp-46655 not bound on any interface — no cluster transport exists INFINISPAN_PORTS_OK

The Infinispan distribution ships no user at all. This is how upstream ships it, not a SecureAnyCloud choice, and it means there is no vendor default in this image for anyone to guess. Your VM created its own administrator on first boot and wrote it to a file that only root can read.

sudo ls -l /root/infinispan-credentials.txt

Expected output:

-rw------- 1 root root 764 Sep 21 01:07 /root/infinispan-credentials.txt

The exact byte count differs between instances because the file embeds your VM's own address, but the mode is always 0600 root:root.

Read the file with the password masked:

sudo sed 's/^\(INFINISPAN_ADMIN_PASSWORD=\).*/\1<hidden>/' /root/infinispan-credentials.txt

Expected output:

# Infinispan Data Grid on Ubuntu 24.04 LTS by sac
# Generated on this VM's first boot — unique to this VM. Keep this file secret. ... INFINISPAN_ADMIN_USER=ispnadmin INFINISPAN_ADMIN_PASSWORD=<hidden> INFINISPAN_HOST=<INFINISPAN_HOST> INFINISPAN_URL=https://<INFINISPAN_HOST>:11222 INFINISPAN_CONSOLE_URL=https://<INFINISPAN_HOST>:11222/console/ INFINISPAN_TLS_CERT=/var/lib/infinispan/conf/server.crt

The realm file the server reads holds only salted hashes, never the password itself:

sudo head -3 /var/lib/infinispan/conf/users.properties

Expected output:

#$REALM_NAME=default$ #$ALGORITHM=encrypted$

To use the credential in the commands below without typing it, read it into shell variables. Do this in each new shell, because the variables do not survive a logout:

U=$(sudo grep '^INFINISPAN_ADMIN_USER=' /root/infinispan-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^INFINISPAN_ADMIN_PASSWORD=' /root/infinispan-credentials.txt | cut -d= -f2-)
echo "administrator: $U"

Expected output:

administrator: ispnadmin

Every path that touches data or configuration is closed without your credential. Check the whole set at once:

sudo /usr/local/sbin/infinispan-verify-auth.sh

Expected output:

door: no credential 401 with a Digest challenge; wrong password 401; unknown user 401 door: this VM's credential accepted over DIGEST-SHA-256 and BASIC (200) TLS: a plaintext request to 11222 is REJECTED anonymous surface is exactly the two health probes, the version banner and the console bundle every data and configuration path is 401 INFINISPAN_AUTH_OK

The image tests each of those checks against a known-bad input, so a check that could never fail cannot quietly pass:

sudo /usr/local/sbin/infinispan-gate-selftest.sh

Expected output:

INFINISPAN_GATE_SELFTEST_OK

You can see the refusal yourself. Without a credential, run:

curl -sk -o /dev/null -w '%{http_code}\n' -X GET https://localhost:11222/rest/v2/caches

Expected output:

401

With your credential, run:

U=$(sudo grep '^INFINISPAN_ADMIN_USER=' /root/infinispan-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^INFINISPAN_ADMIN_PASSWORD=' /root/infinispan-credentials.txt | cut -d= -f2-)
curl -sk --digest -u "$U:$P" https://localhost:11222/rest/v2/caches

Expected output:

["___protobuf_metadata","___script_cache"]

Those two entries are Infinispan's own system caches. Your own caches appear alongside them.

Browse to your VM's console:

https://<INFINISPAN_HOST>:11222/console/

Your browser warns about the certificate because first boot generated a self-signed one for your VM's address. Accept it for now, and replace it with your own in Step 13. Sign in with the administrator from Step 6.

The console opens on Data container, which lists every cache on the node with its type, health and features.

A cache that loses everything on restart is fine for a pure read-through cache but useless for a session store. This image ships a cache template called persistent. Every cache that you create from it writes through to disk and reloads on start.

Create one and put three entries in it:

U=$(sudo grep '^INFINISPAN_ADMIN_USER=' /root/infinispan-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^INFINISPAN_ADMIN_PASSWORD=' /root/infinispan-credentials.txt | cut -d= -f2-)
curl -sk --digest -u "$U:$P" -X POST 'https://localhost:11222/rest/v2/caches/sessions?template=persistent' for k in alice bob carol; do
curl -sk --digest -u "$U:$P" -X PUT -H 'Content-Type: text/plain' \
  --data-binary "session-for-$k" "https://localhost:11222/rest/v2/caches/sessions/$k" done
curl -sk --digest -u "$U:$P" 'https://localhost:11222/rest/v2/caches/sessions?action=size'

Expected output:

3

Read one back:

U=$(sudo grep '^INFINISPAN_ADMIN_USER=' /root/infinispan-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^INFINISPAN_ADMIN_PASSWORD=' /root/infinispan-credentials.txt | cut -d= -f2-)
curl -sk --digest -u "$U:$P" https://localhost:11222/rest/v2/caches/sessions/alice

Expected output:

{"_type":"string","_value":"session-for-alice"}

The entries are on disk as well as in memory:

ls /var/lib/infinispan/data/sessions/

Expected output:

data index sessions.lck

You can do all of this in the console instead. Select Create a cache, choose the persistent template, and then use the cache's Entries tab to add and browse entries.

This is the difference that the persistent template makes. Restart the server and read the same key back:

sudo systemctl restart infinispan </dev/null sleep 20
U=$(sudo grep '^INFINISPAN_ADMIN_USER=' /root/infinispan-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^INFINISPAN_ADMIN_PASSWORD=' /root/infinispan-credentials.txt | cut -d= -f2-)
curl -sk --digest -u "$U:$P" https://localhost:11222/rest/v2/caches/sessions/alice

Expected output:

{"_type":"string","_value":"session-for-alice"}

A cache created without the template is memory-only and comes back empty. That is the correct behavior for a read-through cache, and it is the reason the template exists for everything else.

The cache's Configuration tab in the console shows exactly what it inherited:

The console's Global Statistics view shows cluster-wide figures for every cache: entries held, memory used, hit and miss rates. Cluster Membership shows the nodes. This image is a single node, so membership shows one member.

The server also exposes metrics in Prometheus format on the same port, behind the same credential:

U=$(sudo grep '^INFINISPAN_ADMIN_USER=' /root/infinispan-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^INFINISPAN_ADMIN_PASSWORD=' /root/infinispan-credentials.txt | cut -d= -f2-)
curl -sk --digest -u "$U:$P" https://localhost:11222/metrics | head -3

Expected output (the exact metric names vary by release):

# HELP base_classloader_loadedClasses_count Displays the number of classes that are currently loaded in the Java virtual machine.
# TYPE base_classloader_loadedClasses_count gauge base_classloader_loadedClasses_count 12345.0

Applications should use Hot Rod, Infinispan's binary protocol. It uses the same port 11222 and the same credential. Configure a Java client like this:

ConfigurationBuilder cfg = new ConfigurationBuilder(); cfg.addServer().host("<INFINISPAN_HOST>").port(11222) .security().authentication() .username("<INFINISPAN_ADMIN_USER>") .password("<INFINISPAN_ADMIN_PASSWORD>") .realm("default") .saslMechanism("SCRAM-SHA-512") .ssl() .sniHostName("<INFINISPAN_HOST>") .trustStorePath("/path/to/server.crt"); RemoteCacheManager cacheManager = new RemoteCacheManager(cfg.build()); RemoteCache<String, String> cache = cacheManager.getCache("sessions"); cache.put("dave", "session-for-dave");

Copy your VM's certificate to the client machine so that the client can verify the connection:

sudo cp /var/lib/infinispan/conf/server.crt /tmp/infinispan.crt && sudo chmod 0644 /tmp/infinispan.crt && ls -l /tmp/infinispan.crt

Then fetch it with scp azureuser@<INFINISPAN_HOST>:/tmp/infinispan.crt . from your workstation. Clients for Go, JavaScript, C++, .NET and Python are documented on the Infinispan clients page.

Anything that cannot speak Hot Rod can use the REST API shown in Step 9. It is a first-class interface, not a fallback.

First boot generated a self-signed certificate that names your VM's address. To use a certificate from your own authority, replace the keystore that the server reads. Point a DNS record at your VM, obtain a certificate for that name, then build a PKCS12 keystore from it and restart:

# On a VM whose DNS name is grid.your-domain.com, with fullchain.pem and privkey.pem
# obtained from your CA (certbot, your internal PKI, or a commercial issuer):
sudo openssl pkcs12 -export -inkey privkey.pem -in fullchain.pem -name server \
  -out /var/lib/infinispan/conf/server.p12 -passout env:KSP
sudo systemctl restart infinispan </dev/null

The keystore password lives in /var/lib/infinispan/conf/infinispan.xml, which only root and the infinispan user can read. Set KSP to that value before running the command above, and keep it out of your shell history.

The cache stores and the persisted cache definitions both live under the server's data directory, so a consistent backup is a copy of that directory taken while the server is stopped:

sudo systemctl stop infinispan </dev/null && sudo tar -czf /var/backups/infinispan-data.tar.gz -C /var/lib/infinispan data && sudo systemctl start infinispan </dev/null && ls -l /var/backups/infinispan-data.tar.gz

For a backup of a running server, or to move data between environments, use the server's own backup endpoint. It produces a single archive that contains caches, templates and counters:

U=$(sudo grep '^INFINISPAN_ADMIN_USER=' /root/infinispan-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^INFINISPAN_ADMIN_PASSWORD=' /root/infinispan-credentials.txt | cut -d= -f2-)
curl -sk --digest -u "$U:$P" -o /dev/null -w 'backup request: %{http_code}\n' \
  -X POST -H 'Content-Type: application/json' -d '{}' \
  https://localhost:11222/rest/v2/container/backups/nightly

Expected output:

backup request: 202

The operating system and the JVM receive security updates through Ubuntu's unattended-upgrades, which is enabled in this image. To apply updates immediately, run:

sudo apt-get update && sudo apt-get install --only-upgrade openjdk-25-jre-headless

To upgrade Infinispan itself, unpack a newer distribution alongside the current one and repoint the service. The configuration and data live outside the distribution directory, under /var/lib/infinispan, so the swap does not disturb them. Contact SecureAnyCloud support before a major version change.

The account is an ordinary properties-realm user, so the server's own CLI changes it. The server re-reads the realm files while it runs, so you need no restart:

sudo ISPN_PASSWORD='<new-password>' /opt/infinispan/bin/cli.sh user password ispnadmin \
  -f /var/lib/infinispan/conf/users.properties -w /var/lib/infinispan/conf/groups.properties

Use user password, not user create, because create refuses an account that already exists instead of replacing it. Update /root/infinispan-credentials.txt afterwards so that the file and the live account agree. Never pass the password as a normal argument. ISPN_PASSWORD exists so that the password does not land in your shell history or in the process table.