Payara Server on Ubuntu 24.04 on Azure User Guide

Overview

Payara Server is a production hardened, GlassFish derived Jakarta EE and MicroProfile application server with clustering, hot deploy, and JPA, JMS and CDI support, managed through a full web based admin console. Install the cloudimg image and you have your own private application server ready to host WAR and EAR applications, managed either through the browser console or the asadmin command line tool. The image installs Payara Server 7.2026.6 (Community edition) and runs it as the dedicated payara system service under OpenJDK 21. Application traffic is served directly on port 8080, while the admin console is bound to the loopback connector 127.0.0.1:4848 and fronted by nginx on port 80 alongside an unauthenticated health endpoint. The domain configuration, deployed applications and logs live on a dedicated Azure data disk. A unique admin password is generated on the first boot of every VM by rotating Payara's default blank admin password, so no VM ever ships with a known or blank credential. A minimal demo Jakarta EE application is pre-deployed so you can confirm dynamic execution immediately. Backed by 24/7 cloudimg support.

What is included:

• Payara Server 7.2026.6 (Community edition) installed from the official Payara distribution and run as the payara system service under OpenJDK 21
• The domain (domain1) relocated onto a dedicated Azure data disk at /var/lib/payara
• The admin console bound to 127.0.0.1:4848, fronted by nginx on port 80
• Port 80 serving an unauthenticated /healthz endpoint for load balancer probes
• Application traffic served directly on port 8080
• A minimal demo Jakarta EE application pre-deployed at the root context, proving real dynamic execution
• A unique admin account password rotated on first boot from Payara's default blank password, recorded in a root only file
• payara.service + 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_D2s_v4 (2 vCPU / 8 GiB RAM) is a reasonable starting point for a JVM based application server; size up for heavier applications. NSG inbound: allow 22/tcp from your management network, 80/tcp (and 443/tcp if you add TLS) for the admin console, and 8080/tcp for application traffic. The admin console is served over plain HTTP by default, so for production put your own domain and a trusted certificate in front of it (see Maintenance).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Payara Server 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). After creation, add an inbound rule for 8080 (application traffic). Review the dedicated data disk on the Disks tab, then Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name payara \
  --image <marketplace-image-urn> \
  --size Standard_D2s_v4 \
  --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 payara --port 80   --priority 1010
az vm open-port --resource-group <your-rg> --name payara --port 8080 --priority 1020

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

systemctl is-active payara.service nginx.service
ss -tlnp | grep -E ':4848|:8080'

Both services report active. Payara Server listens on port 8080 for application traffic directly, while the admin console listens only on the loopback address 127.0.0.1:4848 and is fronted by nginx on port 80.

Step 5 - Retrieve your admin password

The Payara admin password is generated uniquely on the first boot of your VM (rotating the product's default blank password) and written to a root only file:

sudo cat /root/payara-credentials.txt

This file contains PAYARA_ADMIN_USER (admin), PAYARA_ADMIN_PASSWORD, the admin console URL and the application URL. Store the password somewhere safe. The file is mode 0600 and owned by root, so only an administrator can read it. The domain configuration, deployed applications and logs live on the dedicated Azure data disk mounted at /var/lib/payara.

Step 6 - Confirm the health endpoint and the demo application

nginx serves an unauthenticated health endpoint for load balancers and probes, and the pre-deployed demo application answers directly on port 8080:

curl -s http://localhost/healthz
curl -s -o /dev/null -w 'HTTP %{http_code}\n' http://localhost/healthz
curl -s -o /dev/null -w 'HTTP %{http_code}\n' http://localhost:8080/

/healthz returns OK with HTTP 200 and never requires authentication, so it is safe for an Azure Load Balancer health probe. Port 8080 returns HTTP 200 from the pre-deployed demo application, which renders its response dynamically (server time, hostname and remote address) on every request.

Step 7 - Verify admin authentication from the command line

The admin console's REST interface uses the same file realm as the browser login, so you can prove the login round trip from the command line. Substitute the value of PAYARA_ADMIN_PASSWORD from Step 5 for <PAYARA_ADMIN_PASSWORD>; because the command embeds your unique password, run it interactively rather than from a script:

curl -u "admin:<PAYARA_ADMIN_PASSWORD>" http://localhost:4848/management/domain
curl -u 'admin:definitely-wrong-pw-xyz' http://localhost:4848/management/domain
curl -u 'admin:' http://localhost:4848/management/domain

The correct per-VM password returns HTTP 200 (authenticated); a wrong password and the original blank default both return HTTP 401 (rejected) - confirming the blank default was rotated away on first boot and only your per-VM password authenticates.

Step 8 - Sign in to the admin console

Browse to http://<vm-public-ip>/. You land on the Payara Server Administration Console login page. Enter admin as the user name and the password from Step 5, then select Login.

Step 9 - Explore the Common Tasks dashboard

After signing in you land on Common Tasks, the admin console dashboard. It shows quick links for administration (change the admin password, list password aliases), monitoring, deployment and resources, plus a navigation tree on the left for the domain, applications, resources and configurations.

Step 10 - View and manage deployed applications

Open Applications in the navigation tree to see every deployed application, including the pre-deployed demo-app. From here you can launch, redeploy, disable or undeploy an application, or select Deploy... to upload your own WAR or EAR file.

Step 11 - View the demo application's response

The pre-deployed demo application answers directly on port 8080 and renders its response dynamically on every request, proving the JSP container is really executing code rather than serving a static page:

http://<vm-public-ip>:8080/

Step 12 - Deploy your own application

From the admin console, open Applications and select Deploy..., then upload your WAR or EAR file and choose a context root. From the command line, use asadmin against the loopback admin port:

asadmin --host localhost --port 4848 --user admin deploy --contextroot /myapp myapp.war

You will be prompted for the admin password (or supply --passwordfile with AS_ADMIN_PASSWORD=<PAYARA_ADMIN_PASSWORD> for non-interactive use). The application then serves on http://<vm-public-ip>:8080/myapp/.

Step 13 - Confirm data lives on the dedicated disk

Payara's domain configuration, deployed applications and logs are stored under /var/lib/payara/domain1 on the dedicated Azure data disk, so they survive OS changes and the disk can be resized independently:

findmnt /var/lib/payara

The mount is backed by a separate Azure data disk captured into the image and re-provisioned on every VM.

Maintenance

• Password: the admin password is set on first boot. To change it, sign in to the admin console and select Change Administrator Password on the Common Tasks dashboard, or run asadmin change-admin-password against the running domain (--host localhost --port 4848, no --domaindir/--domain_name - those flags force local mode, which this product's file realm does not support).
• TLS and certificates: the appliance serves the admin console over plain HTTP on port 80. For production, point a DNS name at the VM, obtain a trusted certificate (for example with certbot / Let's Encrypt), and front the console with nginx TLS on port 443. Payara also supports enabling secure admin for encrypted remote administration.
• Clustering: Payara Server supports Domain Data Grid (DDG) clustering across multiple instances for high availability and session replication; see the Payara documentation for adding instances to this domain.
• Deploying applications: deploy WAR/EAR files from the admin console's Applications page or with asadmin deploy. The pre-deployed demo-app occupies the root context (/); undeploy it or choose a different context root for your own application.
• Storage: all Payara state (domain configuration, deployed applications, logs) lives under /var/lib/payara on the data disk; back up that volume to protect your applications and configuration.
• Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.

Support

cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.