WildFly Application Server: a Jakarta EE runtime you build from source

What WildFly is for, and who ends up running it

WildFly is a Jakarta EE and MicroProfile application server. The README lists four properties it aims at: fast startup, small footprint, modular design, and unified configuration and management. That last one is the real differentiator. A WildFly installation is not just a servlet container with a few extras bolted on; it is a managed runtime where subsystems (datasources, messaging, security, clustering) are configured through a single management model rather than scattered XML files. The repository layout confirms the scope: top-level directories include batch-jberet, bean-validation, clustering, concurrency, connector, datasources-agroal, ee-security, ejb3, elytron-oidc-client, health, iiop-openjdk, jaxrs, jpa, jsf, mail, messaging-activemq, metrics, microprofile, mod_cluster, naming, observability, and pojo. Each is a subsystem, not a sample. The audience is Java teams that need more than HTTP: applications using JPA, JMS, EJB, batch processing, or MicroProfile health and metrics endpoints. If your application is a single Spring Boot jar behind a reverse proxy, WildFly is heavier than the problem requires.

Modular architecture and the two output directories

The README describes a modular design, and the build reflects it. After mvn install, WildFly appears in two directories with different purposes. The build directory contains a build based on Maven artifact resolution for module configuration. The dist directory contains a full distributable build. The README is explicit about when each matters: build is better for iterating on subsystem or module development because there is no need to rebuild all of WildFly or copy JAR files around on every change, while dist suits a full build for development or test purposes. That split is the most useful thing in the README and the easiest to get wrong. Pick build for a subsystem patch loop and dist when you want something you could hand to another machine. The modular design also means configuration is layered: the management model holds subsystem settings, and the server assembles modules at boot rather than loading one flat classpath.

Building WildFly from source with mvnw

The README lists three prerequisites: JDK 17 or newer, Maven 3.6.0 or newer (3.9.14 or a higher Maven 3 is recommended), and on *nix systems a file-descriptor limit of at least 4096 for the user running the build. Check the first two before anything else.

java -version
mvn -v
ulimit -n

If Java reports 17 or later and Maven reports 3.6.0 or later, you can build. The repository ships a Maven Wrapper, so you do not need your own Maven installation. On Linux the README gives ./mvnw install; on Windows it gives mvnw install. Either downloads and installs the required Maven version to ~/.m2/wrapper if necessary and runs it from there.

./mvnw install

With your own Maven, the equivalent is mvn install. After a successful build, change into the bin directory of the versioned build output and start the server. The README shows domain mode and standalone mode as separate scripts.

cd build/target/wildfly-[version]/bin
./standalone.sh

Standalone mode runs one server process. Domain mode, started with ./domain.sh, runs a host controller and servers under it, which is what you want when several instances must share configuration. To stop a running server, press Ctrl + C, or use the CLI: ./jboss-cli.sh --connect command=:shutdown. The README points to the Getting Started Guide in the WildFly documentation for more on starting and stopping.

Testing, and what the testsuite actually covers

The README gives two entry points. For basic smoke tests, mvn test. For everything, mvn install -DallTests. The testsuite is split into submodules that can be run individually to speed up development, and the README links to a WildFly Integration Testsuite User Guide in the docs directory. That link is worth reading before you assume -DallTests is a quick check; the README frames it as the full run, not a sanity pass. The distinction matters in CI: a subsystem change that passes mvn test may still fail integration coverage that exercises the management model end to end. There is also a check_logging.sh script at the repository root, which suggests logging output is treated as something worth checking rather than ignored.

Where WildFly is the wrong choice

The honest limitation is weight. WildFly is a full Jakarta EE runtime with dozens of subsystems, and the README's own selling points (fast startup, small footprint) are relative to other application servers, not to a servlet container. If you deploy one WAR that serves JSON and talks to a database, Tomcat plus a few libraries will start faster, use less memory, and give you fewer moving parts to configure. The build story is the second constraint. Building from source needs JDK 17 or newer, Maven, and on *nix a raised file-descriptor limit; the README notes the 4096 minimum may need to be higher depending on other i/o intensive processes on the machine. That is a real prerequisite, not a formality. Third, choosing between build and dist is a decision the README makes you make explicitly, and picking the wrong one for your workflow costs time. Finally, the README does not document rollback, downgrade paths, or patch procedures for a running installation; those live in the documentation site, and you should read them there before planning an upgrade.

WildFly versus Tomcat: the actual difference

The comparison people search for is WildFly versus Tomcat, and the difference is scope rather than speed. Tomcat is a servlet container: it implements the web tier and leaves JPA, JMS, EJB, batch, and transaction management to whatever libraries you add. WildFly implements those as managed subsystems with a unified configuration and management model, so a datasource is a management resource you configure once, not a connection pool you wire by hand in application code. That model is what domain mode builds on: one host controller can drive several server instances sharing configuration, which Tomcat does not offer without additional tooling. The trade is that you accept the application server's configuration surface and its startup cost in exchange for not assembling and maintaining that stack yourself. If you already have a working Spring Boot or plain Tomcat deployment, migrating to WildFly is a deliberate move toward standards-based packaging, not a performance upgrade.

Licence and the cost of staying current

WildFly is licensed under Apache License 2.0, and the repository carries LICENSE.txt. There is also an MIT_CONTRIBUTORS.txt file at the root, so the project tracks more than one licence artifact; if you redistribute WildFly or a derivative, read both files rather than assuming a single licence covers everything in the tree. This is a description of what the repository contains, not legal advice. On maintenance, the last push to main was on 2026-09-23, and the most recent release listed is 41.0.1.Final from 2026-08-26, with 41.0.0.Final before it in July 2026. The project is not archived. Upgrading between minor releases means re-reading the management model changes for the subsystems you use, because configuration written against one release is not guaranteed to load unchanged in the next. Budget for that review each cycle rather than treating the upgrade as a version bump.

Editorial conclusion

Adopt WildFly if you need a full Jakarta EE and MicroProfile runtime, want domain mode to manage several servers from one controller, and are comfortable building from source or consuming a release. Do not adopt it if you only need a servlet container: Tomcat starts smaller and asks less of you. Before committing, verify that the build directory you intend to run (build or dist) matches how you plan to iterate, and confirm your JDK is 17 or newer with java -version.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. wildfly/wildfly on GitHub