WildFly - Hardened Jakarta EE Application Server

What is WildFly

WildFly is an open-source Jakarta EE 10 application server written in Java, used to deploy and run WAR and EAR applications. It implements the full Jakarta EE web and platform profiles: servlets and JSP, JAX-RS REST services, WebSocket, CDI, JPA/Hibernate, Bean Validation, JTA transactions, JMS messaging (ActiveMQ Artemis), and Jakarta Security. It ships a modular, fast-booting runtime with a web management console, a scriptable jboss-cli, a deployment scanner for drop-in deployments, and datasource and connection-pool management. This image runs WildFly in standalone mode on OpenJDK 17 with an explicitly sized JVM heap. WildFly is fully community open source under LGPL-2.1, with no open-core feature gating and no vendor lock-in.

Why self-host WildFly

Running WildFly on a VM you control keeps your Java applications and the data they process inside your own tenant rather than a managed platform service. Self-hosting suits teams with data residency requirements, organisations operating under GDPR, HIPAA or ISO 27001, and any product where the application runtime and its configuration must stay within your own perimeter with no per-application fees. WildFly is LGPL-2.1, fully auditable, with no vendor lock-in.

What this VM image adds

Security hardening:

• Random management admin user generated per instance at first launch (add-user) - no default credential - stored in /root/wildfly-credentials.txt (mode 0600)
• Application and management ports bound to 127.0.0.1 only - WildFly's HTTP listener (8080) and the management interface (9990) are never exposed directly; nginx terminates TLS on port 443 and proxies to the loopback application port
• Self-signed TLS certificate generated at build and replaceable with your own CA-signed certificate (certbot is pre-installed)
• Standalone mode with a non-root service user and an explicitly sized JVM heap (-Xms/-Xmx)
• UFW firewall - TCP 443 open externally for buyer use, TCP 22 for SSH; all other inbound dropped; Azure IMDS and WireServer egress pre-configured
• fail2ban - SSH brute-force protection
• AppArmor - mandatory access control
• CVE scan - every image is scanned with Trivy before release

OS hardening (CIS Level 1):

• CIS Ubuntu 24.04 LTS Level 1 Benchmark via ansible-lockdown
• auditd for system call auditing of critical paths
• SSH hardening - PasswordAuthentication disabled, key-only access, PermitRootLogin no, LoginGraceTime 60
• Kernel hardening - SYN cookies, ASLR, rp_filter, kexec disabled, IPv6 off
• /tmp as tmpfs with nosuid, nodev, noexec

Compliance artifacts (inside the VM):

• SBOM - CycloneDX 1.6 at /etc/lynxroute/sbom.json with WildFly pinned by version, PURL, LGPL-2.1 license, supplier, and hash
• CIS Conformance Report at /etc/lynxroute/cis-report.html (OpenSCAP, Azure tailoring profile, 0 FAIL rules)
• Tailored CIS profile at /usr/share/doc/lynxroute/CIS_TAILORED_PROFILE.md
• Operator credentials file at /root/wildfly-credentials.txt (mode 0600) with the management admin username and password

Quick Start

1. Deploy VM from Azure Marketplace (Standard_D2s_v3 recommended)
2. Open NSG: TCP 443 from your trusted sources, TCP 22 from your management IPs only
3. SSH: ssh -i key.pem azureuser@<PUBLIC_IP>, then sudo cat /root/wildfly-credentials.txt for the management admin password
4. Open https://<PUBLIC_IP>/ in your browser and accept the self-signed certificate warning - the WildFly welcome page confirms the server is running
5. Deploy your application by copying a .war or .ear file into /opt/wildfly/standalone/deployments/ - the deployment scanner deploys it automatically

The management console listens on 127.0.0.1:9990 and is not exposed; reach it with an SSH tunnel (ssh -L 9990:127.0.0.1:9990) and log in with the management user from the credentials file. Replace the self-signed certificate with a CA-signed one for production, then run sudo systemctl reload nginx.