How to Access the WildFly Admin Console

The WildFly Admin Console, also known as the HAL Management Console, is a web-based interface that allows administrators to manage, configure, and monitor a running WildFly server. This guide covers the most up-to-date methods to access the Admin Console in WildFly 40 and 41, including:

• Best practices and troubleshooting tips
• Configuration of management interfaces
• Security options such as using HTTPS and OpenID Connect (OIDC)
• Production-readiness considerations for containerized and cloud deployments

WildFly Admin Console Default URL

The default URL for WildFly Management Console is http://localhost:9990. This is the default URL in both Standalone Mode and in Domain mode.

Upon installation, you cannot connect to WildFly Management Console because there is no default Admin user for the Management Console. To add a new user execute the add-user.sh script within the bin folder of your WildFly installation and enter the requested information. By default, WildFly uses the Realm "ManagementRealm".

Here is how to add a Management User for WildFly Management Console:

$ ./add-user.sh

What type of user do you wish to add?
 a) Management User (mgmt-users.properties)
 b) Application User (application-users.properties)
(a): a

Enter the details of the new user to add.
Using realm 'ManagementRealm' as discovered from the existing property files.
Username : admin123
Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
 - The password should not be one of the following restricted values {root, admin, administrator}
 - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
 - The password should be different from the username
Password :
Re-enter Password :
What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[  ]:

Besides, you can also add an admin user in non-interactive way as follows:

./add-user.sh -m -u administrator1 -p password1!

Please note that, by default, WildFly enforces the password recommendations shown above but will still let you proceed with a weaker password after a confirmation prompt. The password restrictions for the add-user utility script can be configured using the $JBOSS_HOME/bin/add-user.properties file.

Then, you can Login to the WildFly Management Console with the User and Password:

If you want to set the WildFly management console to a different IP Address, check the following tutorial: How to bind WildFly to an IP address

Unable to access WildFly Admin console

If you are unable to access WildFly Admin console you should check a set of items. Here is our recommended check-list:

Is the Admin Console actively listening?

The Admin Console listens to the management interface, which by default is:

<interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
</interface>

Then, the interface uses by default one of the following addresses:

<!-- HTTP Connection -->
<socket-binding name="management-http"
                interface="management"
                port="${jboss.management.http.port:9990}"/>

<!-- HTTPS Connection -->
<socket-binding name="management-https"
                interface="management"
                port="${jboss.management.https.port:9993}"/>

Therefore, firstly check from your logs to see if the Admin Console is actively listening:

INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990

If you cannot find the above log, check for any start up errors (such as Port already bound).

On a Linux machine, you can find which process is engaging a port with the following command:

netstat -tulpn | grep 9990

tcp        0      0 127.0.0.1:9990          0.0.0.0:*               LISTEN      12024/java

On a Windows machine the equivalent command is:

netstat -ano | findstr :<port number>

In the above examples, the Management Console is bound to the loopback address, which means you cannot access it remotely.

To bind WildFly management interface on all available addresses, you can start it as follows:

./standalone.sh -Djboss.bind.address.management=0.0.0.0

If you are running WildFly in a container (Docker, Podman, Kubernetes, or OpenShift), remember that binding to 127.0.0.1 alone will also prevent access from outside the container network. In containerized deployments it's common to bind the management interface to 0.0.0.0 only on trusted internal networks, and to expose it externally through a properly secured Ingress/Route rather than a raw port mapping.

Try with a clean browser cache

If the problem persists, make sure that the browser cache is clean. The simplest way is to test with a browser in incognito mode.

Are you hitting a bug ?

One possibility is that you might be hitting a bug. For example, there could be issues with the version of the browser you are using. To learn more, try to access the Web Console page in Developer Mode

Check the errors in the Console if any. As a matter of fact, the Admin Console uses a set of modern JavaScript APIs like Promise, Fetch or Worker. You should check if your Browser version currently supports these tools.

To check your current HAL version, you can run the following find in the application server's module tree:

$ find . -name hal*.jar
./system/layers/base/org/jboss/as/console/main/hal-console-{version}-resources.jar

The exact version number depends on the WildFly release you are running, since each WildFly version ships with the matching HAL console build. Note that the HAL team is also working on a next-generation console — HAL Foundation — a shared foundation intended to power future management console implementations across WildFly and related projects, so expect the console internals to evolve further in upcoming releases.

Failing authentication ?

Next, if you are failing the login, verify which security-realm you are using to authenticate. As an example, this is the management-interfaces configuration against a Realm called "LDAPRealm":

<management-interfaces>
    <http-interface security-realm="LDAPRealm" http-upgrade-enabled="true">
        <socket-binding http="management-http"/>
    </http-interface>
</management-interfaces>

When you have troubles with security and login, we recommend enabling security loggers: How to debug WildFly security issues

Wrong bookmark ?

Finally, if you still cannot see the Login Pop-up please verify that you are not refreshing the wrong page. You might have bookmarked by mistake the error page, which is localhost:9990/error/index.html

Securing WildFly Admin Console

This tutorial covers accessing the Web Console with no security in place. In a production environment it is essential to consider some secure options. Continue reading the security options in these articles:

How to secure WildFly console with SSL or Database: Securing JBoss / WildFly Management Interfaces: the easy way

Secure WildFly console using Keycloak: Securing WildFly Management Console with Keycloak

For OpenID Connect (OIDC) based security, WildFly's OIDC support continues to mature with each release — for example, recent WildFly releases have promoted OIDC scope handling and OIDC logout to broader stability levels, so it's worth checking the release notes for your specific version if you rely on OIDC to protect the management console or your applications.

WildFly Admin Console in Containers and Kubernetes/OpenShift

When running WildFly on Kubernetes or OpenShift, avoid exposing the management interface (port 9990/9993) publicly. Some best practices for production-grade deployments include:

• Keep the management interface bound to a private/internal network and access it only via kubectl port-forward, a bastion host, or a dedicated internal Route/Ingress.
• Prefer the WildFly Maven Plugin or Galleon-based provisioning to build minimal, purpose-built server images rather than shipping the full distribution with the console always exposed.
• Where the console itself isn't strictly required in production, consider managing the server exclusively through the CLI, the Management HTTP API, or the WildFly Operator/Helm charts, and reserve the graphical console for staging or troubleshooting sessions.
• Always front the management interface with TLS and, ideally, OIDC or another centralized identity provider rather than local file-based realms.

Conclusion

The WildFly Admin Console is a powerful tool for managing your application server, and recent WildFly releases keep pushing it forward, including a move to Jakarta EE 11 and continued investment in HTTPS access, OIDC authentication, and a next-generation HAL console foundation. Whether you prefer a web interface, CLI, or REST API, WildFly has multiple access strategies to suit your needs — and choosing the right one for each environment (development, staging, or production/Kubernetes) is key to keeping your server both manageable and secure.

Frequently Asked Questions

What is the default port for the WildFly Admin Console?

The default HTTP port is 9990 and the default HTTPS port is 9993. Both are bound to the management interface, which defaults to the loopback address 127.0.0.1.

Why can't I log in to the WildFly Admin Console even with the correct credentials?

This usually points to a mismatch between the security realm configured on the http-interface and the realm where the user was created with add-user.sh. Double-check that both reference the same realm name (by default ManagementRealm), and enable security logging if the problem persists.

How do I access the WildFly Admin Console remotely?

By default the management interface only listens on 127.0.0.1, so it isn't reachable from other machines. Start WildFly with -Djboss.bind.address.management=0.0.0.0 to bind it to all interfaces, but only do this on a trusted network, and pair it with TLS and strong authentication in production.

Can I reset the WildFly management console password?

Yes. Re-run add-user.sh for the existing username; the utility lets you update the password and roles for a user that already exists in mgmt-users.properties.

Should the Admin Console be exposed in production?

Generally no, not publicly. Keep it on an internal network only, protect it with TLS and centralized authentication (LDAP, Keycloak, or OIDC), and prefer the CLI, Management HTTP API, or the WildFly Operator/Helm charts for automated, repeatable operations in Kubernetes or OpenShift environments.

Which WildFly versions does this guide apply to?

The steps and defaults described here apply to current WildFly releases, including WildFly 40 (Jakarta EE 11) and the WildFly 41 development line. The overall workflow — add-user.sh, the management interface, and the HAL console — has been stable across many major versions, though the bundled HAL console build number changes with each release.

What's the difference between the Admin Console, the CLI, and the Management HTTP API?

All three talk to the same underlying management model. The Admin Console (HAL) is the graphical option, the CLI (jboss-cli.sh) is best for scripting and automation, and the Management HTTP API (accessed via /management) is useful for integrating WildFly configuration into external tools or pipelines.

Do I need OIDC or Keycloak to secure the Admin Console?

No, it's optional but recommended for production. You can also secure it with a local ManagementRealm, an LDAP-backed realm, or a database-backed realm. OIDC/Keycloak is a good fit when you already centralize authentication for your organization and want single sign-on across the console and your applications.