How to Set and Load Properties in WildFly

If you are working with WildFly or JBoss EAP in 2026, managing system properties and application configurations effectively is essential for containerized deployments, CI/CD pipelines, and cloud-native workloads. Whether you need to inject environment-specific variables, manage secret values, or configure tuning parameters, understanding how to set and load properties in WildFly ensures your applications remain portable, maintainable, and aligned with modern DevOps practices. This updated guide walks through seven ways to inject system properties into WildFly — from JVM arguments and CLI commands to a startup-script flag most tutorials skip entirely, plus the environment-variable and Kubernetes/OpenShift-native approaches.

In a bare-metal installation of WildFly, there are several strategies to load properties:

1. Add the System Properties as JVM arguments to the startup script
2. Include the System Properties in the WildFly configuration (standalone.xml/domain.xml or CLI)
3. Load an entire properties file at boot with the --properties startup flag
4. Include the Application Properties in a module of the application server
5. Set properties at the deployment level via META-INF/jboss.properties
6. Use MicroProfile Config for externalized, dynamically-reloadable configuration
7. Inject the System Properties through an environment variable

Let's see them all in detail.

1. Setting a System Property as a JVM Argument

Firstly, you can add a System Property using -D, as for every Java application. For example, you can add MSG to the startup script of WildFly as follows:

$ ./standalone.sh -DMSG=Hello

Next, edit the standalone.conf file and add it to the JAVA_OPTS variable, so it applies on every startup without retyping it:

JAVA_OPTS="$JAVA_OPTS -Dproperty=value"

Finally, in domain mode, add it as a JVM option in the host.xml file:

<jvm-options>
    <option value="-server"/>
    <option value="-XX:MetaspaceSize=96m"/>
    <option value="-XX:MaxMetaspaceSize=256m"/>
    <option value="-Dproperty=value"/>
</jvm-options>

2. Setting System Properties in the WildFly Configuration

The other option requires that you either add your system property directly into the configuration file or use the CLI. Let's see the configuration file approach first:

• In Standalone mode, the change goes into standalone.xml
• In Domain mode, the change goes into domain.xml

Add the system-properties element right after the extensions element:

<extensions>
    . . .
</extensions>

<system-properties>
    <property name="my.project.dir" value="/home/francesco"/>
</system-properties>

Finally, you can read/write System Properties from the CLI as follows:

$ ./bin/jboss-cli.sh
[standalone@localhost:9990 /] /system-property=foo:add(value=bar)
[standalone@localhost:9990 /] /system-property=foo:read-resource
{
    "outcome" => "success",
    "result" => {"value" => "bar"}
}

(Note: the management CLI prompt above connects on port 9990 — current WildFly and JBoss EAP use this single port for both the Web console and CLI. Older tutorials showing port 9999 are referring to the long-EOL AS 7/EAP 6 generation's separate native management port.)

3. Loading a Whole Properties File at Boot with --properties

A method genuinely worth knowing that most tutorials skip: both standalone.sh and domain.sh accept a -P / --properties flag that loads an entire properties file at boot and registers every entry as a system property, before the server configuration is even processed. It's the single most convenient option when you have more than a couple of properties to set, since it avoids stacking a long list of individual -D flags:

$ ./standalone.sh --properties=/path/to/my.properties

Where my.properties is a plain Java properties file:

my.project.dir=/home/francesco
feature.flag.enabled=true
external.api.timeout=5000

The URL form also works, which is handy if the properties file is served from somewhere other than the local filesystem:

$ ./standalone.sh --properties=http://config-server.internal/wildfly-app.properties

On Kubernetes/OpenShift, this pairs nicely with a mounted ConfigMap: mount the ConfigMap as a volume containing a properties file, then point --properties at the mounted path in your container's start command — one flag instead of dozens of individual -D arguments spread across your Deployment manifest.

4. How to Load Application Properties from a Module

If you want to load your Application Properties from a folder, we recommend placing your property file in a module and using that module in your application.

Let's see how to do it. Place the property file (say file.properties) in the "bin" folder of the application server and launch jboss-cli.sh:

$ jboss-cli.sh

Execute the following command:

module add --name=configuration --resources=file.properties

Then, the following structure will be created under the "modules" folder:

configuration/
└── main
    ├── file.properties
    └── module.xml

As you can see, our module named "configuration" has been defined. The module.xml file contains the list of resources available in that module:

<?xml version='1.0' encoding='UTF-8'?>

<module xmlns="urn:jboss:module:1.1" name="configuration">
    <resources>
        <resource-root path="file.properties"/>
    </resources>
</module>

Finally, if you want to use this module at the application level, add it to your jboss-deployment-structure.xml:

<jboss-deployment-structure>
    <deployment>
        <dependencies>
            <module name="configuration" export="TRUE"/>
        </dependencies>
    </deployment>
</jboss-deployment-structure>

As an alternative, if the property file is shared between multiple applications, you can include it in the list of global modules within your server configuration:

<subsystem xmlns="urn:jboss:domain:ee:1.0">
    <global-modules>
        <module name="configuration" slot="main" />
    </global-modules>
</subsystem>

When the property file is available as a module, you can load it with the following code:

Properties props = new Properties();

try {
    java.io.InputStream stream = Thread.currentThread()
            .getContextClassLoader()
            .getResourceAsStream("file.properties");
    // Read the Properties file
    props.load(stream);
} catch (IOException e) {
    e.printStackTrace();
}

5. Setting System Properties at the Application Level

Next, it's worth mentioning that WildFly can use a META-INF/jboss.properties file to set System Properties at the deployment level — scoped to that one application only.

Here is an example application which includes the jboss.properties file to set System Properties only for that deployment:

test.war
├── index.jsp
└── META-INF
    └── jboss.properties

Therefore, if jboss.properties includes the following:

foo=bar

Then your index.jsp will display the property "foo":

<%
 out.println("foo: " + System.getProperty("foo"));
%>

6. Setting Properties in MicroProfile Applications

Beyond setting properties in standalone.xml or using CLI commands, consider using MicroProfile Config, which is natively supported on WildFly, to externalize and dynamically inject configuration into your applications without restarting the server. With MicroProfile Config, you can load properties from environment variables, system properties, and external files, enabling 12-Factor App best practices for modern workloads. Check this article to learn more: Configuring Microservices with MicroProfile Configuration

Adding Properties from the CLI Using a File

The JBoss CLI itself does not support file operations such as setting properties directly from a file's contents. However, you can easily work around this with a bash script that reads a file into a variable, then expand the shell variable when calling the CLI. For example:

CUSTOMERS=$(cat customers.txt)
./jboss-cli.sh -c --commands="/system-property=users:add(value=\"${CUSTOMERS}\")"

7. Injecting Properties Through Environment Variables

Since cloud use-cases rely more often on environment variables than system properties, WildFly also supports injecting properties directly from environment variables — this has been available since WildFly 25, which means it applies to every currently supported WildFly and JBoss EAP release today.

For example, if you have the following configuration:

<file relative-to="jboss.server.log.dir" path="${log_file:server.log}"/>

Then, you can inject the value of the path element as follows:

$ export LOG_FILE=wildfly.log

$ ./standalone.sh

Finally, note that a System property takes precedence over an environment variable if both are defined for the same expression.

Setting Properties in a Kubernetes Environment

Finally, if you are deploying your applications on OpenShift or Kubernetes, the most common option to pass properties to the WildFly runtime is via environment variables. For example, if you are deploying WildFly using Helm Charts, you can add them in the env section of your YAML file:

build:
  uri: https://github.com/wildfly/quickstart.git
  ref: main
  contextDir: microprofile-config
  mode: bootable-jar
  env:
    - name: MAVEN_ARGS_APPEND
      value: -Pbootable-jar-openshift -Djkube.skip=true
deploy:
  replicas: 1
  env:
    - name: CONFIG_PROP
      value: Hello from OpenShift

(Use ref: main or the current release tag rather than an old, hardcoded version like 27.0.0.Final — WildFly quickstart tags move forward with every release, and pinning an ancient one in a copy-pasted example is an easy way to end up building against long-superseded code.)

Besides, if you want to externalize the properties — for example from a ConfigMap — you can reference the ConfigMap from your deploy section as follows:

deploy:
  replicas: 1
  envFrom:
    - configMapRef:
        name: <name-of-your-config-map>

To learn more about deploying WildFly on Kubernetes using Helm Charts, check this article: WildFly on the Cloud with Helm

The same runtime and configuration mechanisms described throughout this article — JVM arguments, standalone.xml, the --properties flag, environment variables — apply identically whether WildFly is packaged as a traditional server distribution or as a Bootable JAR, since it's the same underlying runtime either way; only the packaging and startup command differ.

Frequently Asked Questions

What's the fastest way to set a dozen properties at once without a huge command line?

Use the --properties=/path/to/file.properties startup flag (Section 3 above) rather than stacking many individual -D arguments — it loads an entire properties file at boot in one shot, and works with local paths or URLs alike.

Which port does the WildFly CLI connect to for reading/writing system properties?

Port 9990 on current WildFly and JBoss EAP releases — the same port used for the web-based Admin Console. Port 9999 was specific to the long-EOL JBoss AS 7 / EAP 6 generation and doesn't apply to current versions.

Does WildFly 25+ support injecting properties from environment variables?

Yes, and since every currently supported WildFly/JBoss EAP release is well past version 25, this feature is available by default — no special flag or opt-in required, just reference the environment variable using the standard ${ENV_VAR:default} expression syntax in your configuration.

Which takes priority if both a system property and an environment variable define the same value?

The system property wins. If you need the environment variable to take effect, make sure no conflicting system property is also being set for the same expression (check startup scripts and any -D flags first).

Should I use standalone.xml, the CLI, or --properties to set configuration?

Use the CLI (or a scripted CLI file) for changes you want to apply and track through the normal management API, standalone.xml edits when you're hand-authoring configuration for version control, and --properties when you have many environment-specific values to inject at boot without touching the server configuration file at all — the last option is usually the cleanest fit for container images meant to run unmodified across environments.

Do I need a different approach for a WildFly Bootable JAR versus a full server distribution?

No — JVM arguments, standalone.xml edits baked in at build time, the --properties flag, and environment variables all work the same way on a Bootable JAR, since it runs the identical WildFly core; only how you start it (java -jar app.jar versus standalone.sh) changes.