“JBoss” is not one installable package. It usually means either Red Hat JBoss Enterprise Application Platform (JBoss EAP), a subscription product with release-specific support matrices, or WildFly, its upstream project with a freely downloadable archive. Identify the product and exact release before choosing a Java runtime or running a command.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
For a general-purpose Ubuntu VPS, the documented archive installation of WildFly is the clearest route. This guide provisions an x86_64 server, installs a compatible JDK, runs WildFly under a dedicated account, verifies it in standalone mode, and registers it with systemd. It also explains what changes when the target is JBoss EAP and why Ubuntu support must be checked against the exact EAP release.
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Choose WildFly or JBoss EAP before installing
The commands below use WildFly because its ZIP or tar distribution is designed to be unpacked on an operating system that supports those archive formats. WildFly 37’s getting-started documentation states that it requires “Java SE 11 or later.” WildFly also offers Galleon provisioning and bootable-jar workflows, but the traditional archive is the most transparent choice for a single VPS.
JBoss EAP is different. It is distributed and supported through Red Hat subscriptions, and its Java and operating-system combinations are tied to particular EAP updates. Running an EAP binary on Ubuntu is not the same as having Ubuntu listed as a certified production platform. Check the support matrix for the exact EAP release, update, JDK vendor, and architecture before committing a production workload.
| Server | Distribution and installation channels | Java guidance | Ubuntu and architecture caveat |
|---|---|---|---|
| WildFly 37 | Freely downloadable ZIP or tar archive; Galleon and bootable-jar options also exist | Java SE 11 or later | The archive method can be installed on operating systems that support the archive format; this is not a Red Hat EAP certification statement |
| JBoss EAP 7.4 | Red Hat subscription distribution, including documented RPM layouts | The matrix covers Red Hat build of OpenJDK, Oracle JDK, Adoptium, IBM, and Azul combinations; Java 17 is limited to particular EAP updates | Use the matrix for the exact release and update; do not assume every Ubuntu release is certified |
| JBoss EAP 8 | Red Hat subscription distribution, including documented RPM layouts | Java 11, 17, and 21 combinations vary by EAP update | The matrix lists tested x86_64 operating systems; confirm Ubuntu supportability and subscription terms separately |
For EAP RPM installations, Red Hat documents paths under /opt/rh/eap7/root/usr/share/wildfly for EAP 7 and /opt/rh/eap8/root/usr/share/wildfly for EAP 8. Those paths describe the RPM layout, not the recommended location for a WildFly archive on Ubuntu.
Prepare the 64-bit Ubuntu VPS
Confirm architecture, privileges, and init system
Provision an x86_64 (64-bit) Ubuntu image with administrator access. The server should use systemd; a normal Ubuntu VPS does. Confirm the basics before installing:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →uname -m
ps -p 1 -o comm=
whoamiuname -m should report x86_64. The process with PID 1 should be systemd, and your account must be able to run commands with sudo. Hardware requirements are workload-dependent; no authoritative minimum RAM or CPU figure is established for all JBoss or WildFly deployments. Size the VPS for your application, peak concurrency, heap, database connections, and any co-located services.
Patch Ubuntu and install Java and archive tools
Update the image first. Then install a JDK, not merely a JRE, because application-server administration and tooling commonly require the full development kit. WildFly 37 accepts Java SE 11 or later; select the JDK required by your exact server release. The following example uses Ubuntu’s OpenJDK 17 package, but use OpenJDK 11 or another supported vendor when the selected release requires it.
sudo apt update
sudo apt full-upgrade -y
sudo apt install -y openjdk-17-jdk unzip tar gzip ca-certificates
java -versionRead the output of java -version and record which executable is selected. If more than one JDK is installed, use Ubuntu’s alternatives mechanism to select the intended one, then run java -version again. The interactive SSH shell is not the service environment; you will set JAVA_HOME explicitly for systemd later.
Create a non-root WildFly account
Do not run the application server as root. Create a system group and a non-login service account. A fixed home directory makes ownership and service configuration predictable:
sudo groupadd --system wildfly
sudo useradd --system --gid wildfly
--home-dir /opt/wildfly
--shell /usr/sbin/nologin wildfly
sudo install -d -o wildfly -g wildfly -m 0750 /opt/wildflyThe account does not need an interactive shell. Grant it read access to the server installation and write access only to the directories that hold configuration, deployments, logs, temporary files, and runtime data.
Download and unpack the exact WildFly release
Obtain the archive and verify it
Download the exact WildFly ZIP or tar archive from the official WildFly release page using a workstation or the VPS. Keep the release number in your deployment notes; upgrades must be checked against the corresponding Java guidance. If the release page publishes a checksum, download that checksum file and verify the archive before extraction. For a SHA-256 checksum file in the usual format:
sha256sum -c wildfly-archive.sha256The command must report an OK result for the archive you intend to install. If no checksum is published for the selected artifact, do not invent one; retain the downloaded file and record its source and release.
Extract under /opt
Transfer the verified archive to /tmp on the VPS, then extract it as an administrator. Ensure that only the intended WildFly archive is present before using the wildcard:
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesls -lh /tmp/wildfly-*.zip /tmp/wildfly-*.tar.gz 2>/dev/null
sudo install -d -m 0755 /optFor a ZIP distribution, run:
ARCHIVE=$(find /tmp -maxdepth 1 -type f -name 'wildfly-*.zip' | head -n 1)
sudo unzip "$ARCHIVE" -d /optFor a tar archive, use the matching command instead:
ARCHIVE=$(find /tmp -maxdepth 1 -type f -name 'wildfly-*.tar.gz' | head -n 1)
sudo tar -xzf "$ARCHIVE" -C /optBoth formats normally create a versioned directory. Point a stable path at that directory so a service file does not need to change on every upgrade:
EXTRACTED=$(find /opt -maxdepth 1 -mindepth 1 -type d -name 'wildfly-*' | head -n 1)
sudo ln -sfn "$EXTRACTED" /opt/wildfly
sudo chown -R wildfly:wildfly "$EXTRACTED"
sudo chown -h wildfly:wildfly /opt/wildflyInspect the result before proceeding:
sudo -u wildfly test -x /opt/wildfly/bin/standalone.sh
ls -ld /opt/wildfly /opt/wildfly/standaloneFor a stricter separation between administrator-managed binaries and runtime data, keep the extracted tree root-owned and change ownership only on the runtime directories. The simpler ownership model above is suitable for an initial single-VPS installation; revisit it when you introduce an automated upgrade process.
Start once in standalone mode
A single VPS normally begins in standalone mode. It has one server configuration and does not require host and domain controllers. Change to the server’s bin directory and launch it as the service account, binding only to loopback for the first test:
Recommended Free Tools
sudo -u wildfly /opt/wildfly/bin/standalone.sh -b 127.0.0.1Leave this process in the foreground and watch the console for Java, permission, or configuration errors. A successful boot creates or updates the standalone configuration and runtime directories. Stop the test with Ctrl-C; do not leave a manually started root-owned or SSH-tied process running alongside systemd.
If the script cannot start, check java -version under the intended account, verify that /opt/wildfly/bin/standalone.sh is executable, and inspect ownership of standalone/configuration, standalone/deployments, standalone/log, standalone/tmp, and standalone/data. The service account must be able to read the installation and write the runtime locations.
Run WildFly with systemd
Use the supplied unit generator when available
WildFly’s documentation describes creating a Linux service after installing from a ZIP archive. The distribution includes generate_systemd_unit.sh, and the documentation provides separate standalone and domain patterns. From the server’s bin directory, view the script’s options and use the mode and names it reports:
cd /opt/wildfly/bin
sudo ./generate_systemd_unit.sh --helpUse the generated standalone unit for a normal one-VPS deployment. The script produces a service unit and an accompanying configuration file; copy each file to the exact destination printed by the script or shown in the WildFly guide. Do not guess a configuration path, and do not mix a generated domain unit with a standalone launch command.
Manual standalone unit when you need an explicit configuration
If you need a small, auditable unit instead of the generator, create a configuration file and unit yourself. This example keeps the application bound to loopback until you deliberately choose an externally reachable address:
sudo install -d -m 0755 /etc/wildfly
sudo tee /etc/wildfly/wildfly.conf >/dev/null <<'EOF'
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
JBOSS_HOME=/opt/wildfly
WILDFLY_BIND=127.0.0.1
EOFAdjust JAVA_HOME to the path installed on your VPS. Confirm it with readlink -f "$(command -v java)" and remove the trailing /bin/java components to obtain the JDK directory. Then create the unit:
sudo tee /etc/systemd/system/wildfly.service >/dev/null <<'EOF'
[Unit]
Description=WildFly Application Server
After=network.target
[Service]
Type=simple
User=wildfly
Group=wildfly
EnvironmentFile=-/etc/wildfly/wildfly.conf
WorkingDirectory=/opt/wildfly
ExecStart=/opt/wildfly/bin/standalone.sh -c standalone.xml -b $WILDFLY_BIND
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
StandardOutput=journal
StandardError=inherit
[Install]
WantedBy=multi-user.target
EOFThis unit deliberately does not prescribe heap sizes: memory settings depend on your application and VPS workload. Add server options only after measuring the workload and documenting the selected values. If you need a separate management bind address, configure it using the server’s supported command-line option or configuration file, rather than exposing the management interface by changing the application bind alone.
Free tools Windows power users keep installed
One-click scans. No signup required.
Load, enable, and start the service
Reload systemd, enable the service for boot, and start it:
sudo systemctl daemon-reload
sudo systemctl enable wildfly
sudo systemctl start wildfly
sudo systemctl status wildfly --no-pagerA healthy unit remains active (running). Read both the unit journal and the standalone server log when diagnosing a failure:
sudo journalctl -u wildfly -b --no-pager
sudo tail -n 100 /opt/wildfly/standalone/log/server.logAfter changing /etc/wildfly/wildfly.conf or the unit file, run sudo systemctl daemon-reload and restart the service. A reboot test is worthwhile once startup succeeds: it verifies that the service does not depend on variables exported only in your SSH session.
Choose standalone or domain mode deliberately
Standalone mode is the normal starting point for one VPS. It keeps configuration and lifecycle management inside one server instance. WildFly’s systemd material also documents domain-mode units, but domain mode is intended for deployments that need managed host and domain controllers. It adds operational complexity and should be selected because the topology requires it, not because the product name contains “domain.”
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →If you choose domain mode, use the domain unit and launch script supplied for that mode, define the host and domain-controller relationships, and test the resulting boot sequence independently. Do not run both standalone and domain services against the same runtime directories. Red Hat’s EAP RPM documentation also warns that multiple domain or host controllers on one machine are not supported for that RPM installation method.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Network exposure and first deployment checks
Bind the application and management interfaces intentionally. During installation, loopback binding is a safe default for testing. When an application must accept traffic from the internet or an internal network, bind only the required application interface and configure the VPS firewall and provider security group to match it.
- Open only ports required by the deployed application and administration workflow.
- Keep the management interface on loopback, a private network, or a VPN whenever possible.
- Confirm listeners with
ss -ltnpand compare them with your intended bind addresses. - Test from an allowed client and from a disallowed network so that firewall rules are verified rather than assumed.
- Do not treat a successful local curl as proof that the service is safely exposed to the public internet.
Deploy an application only after the server starts cleanly under systemd. Confirm that the deployment is owned by the service account, that the server log records the deployment outcome, and that a restart preserves the intended configuration.
JBoss EAP on Ubuntu: what “supported” means
JBoss EAP support is release-specific. The EAP 7.4 compatibility material lists tested combinations of JDK vendors and versions, with Java 17 available only for particular updates. EAP 8 lists Java 11, 17, and 21 combinations by update and identifies tested x86_64 operating systems. Those matrices enumerate Red Hat Enterprise Linux and Windows combinations; they do not establish that every Ubuntu release is a certified EAP platform.
Before installing EAP on an Ubuntu VPS:
- Record the exact EAP major version and update you intend to run.
- Open that release’s support matrix and select a listed JDK vendor, version, and architecture.
- Check the operating-system column and subscription terms for Ubuntu supportability. If Ubuntu is not listed, ask Red Hat or your support provider for a written position before production use.
- Use the EAP distribution and installation method supplied with your subscription. Do not substitute a WildFly archive and assume it has EAP support or EAP patch entitlement.
- Keep the EAP server, JDK, and operating-system versions recorded together; re-check the matrix whenever one changes.
An Ubuntu VPS can be a practical laboratory or application host, but “it starts” and “it is supported by the vendor” are different outcomes. Make that distinction explicit in your operations documentation.
Troubleshoot the common failure points
The wrong Java runtime is being used
Compare java -version in your shell with the value available to systemd. Set JAVA_HOME in the generated configuration or /etc/wildfly/wildfly.conf; setting it only in ~/.profile does not affect a system service. After changing it, reload systemd and restart WildFly, then inspect journalctl -u wildfly -b.
Systemd exits immediately
Read the first error, not only the final “failed” line. Typical causes are an incorrect JAVA_HOME, an invalid ExecStart path, a non-executable script, or a service account that cannot write its runtime directories. Run the exact ExecStart command manually as wildfly with the same working directory to distinguish a server error from a unit-file error.
Permission errors appear after an upgrade
Replacing the versioned directory can leave the new tree owned by root. Reapply ownership to the installation and verify the writable standalone directories. If you intentionally keep binaries root-owned, grant the service account ownership or write permission on runtime paths only, and make that rule part of the upgrade procedure.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteThe service is running but clients cannot connect
Check the configured bind address, listener state, VPS firewall, and provider security group in that order. A process bound to 127.0.0.1 is reachable only from the VPS. A process bound externally can still be blocked by a security group. Use ss -ltnp and a test from an authorized remote client; do not open every port as a diagnostic shortcut.
An EAP or WildFly upgrade fails
Re-check the Java compatibility information for the new server release before changing the JDK. WildFly’s Java requirement and EAP’s vendor-and-update matrix are not interchangeable. Preserve the old installation until the new version has passed startup, deployment, log, and rollback checks, and never point two concurrently running services at the same writable runtime directory.
Quick Recap
Operational checklist
- Product identified as WildFly or a specific JBoss EAP release.
- x86_64 Ubuntu VPS with administrator access and systemd.
- JDK selected from the exact server release guidance.
- Archive checksum verified when the release provides one.
- Dedicated non-login
wildflyaccount owns or can read the installation. - Standalone startup tested before creating the service.
JAVA_HOME, bind address, options, and log handling defined in the systemd environment.- Unit enabled and checked with
systemctl statusandjournalctl -u. - Only necessary network ports exposed; management access restricted.
- EAP supportability confirmed for the exact Ubuntu release, EAP update, JDK, and architecture.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
