Custom environment variables are placeholders for values your application reads at runtime — connection strings, feature flags, paths, credentials in dev, anything you would otherwise hard-code. The platform exposes three ways to set them. Pick the one that matches what the variable is for.
- The dashboard variables panel — the canonical surface, persisted by the platform.
- Shell configuration files (
~/.bashrc,~/.bash_profile) — interactive shell only. variables.conf— Java application servers, reaches the JVM as-Dflags.
Through the dashboard variables panel
This is the right surface for application configuration. Values set here survive container restarts and rebuilds.
- Hover over the node group in the dashboard, expand the Additionally menu, and pick Variables.
- In the panel, add, edit, or remove variables using the toolbar buttons.
- Click Apply.
The platform’s Docker container implementation lets you reference existing variables when defining new ones. For example, setting MY$HOME resolves to the literal expansion of $HOME — so if HOME=/root, MY$HOME becomes MY/root.
A container restart applies the new values to running processes.
Through shell configuration files
Use this when the variable needs to exist for interactive shell sessions — typically because a developer SSHing in expects $VAR_NAME to be set.
Two files matter:
~/.bash_profile— sourced once per login shell.~/.bashrc— sourced for every new interactive shell.
The platform sources ~/.bashrc from ~/.bash_profile automatically, so you only need to maintain ~/.bashrc.
To add a variable:
-
Open an SSH connection to the container — the embedded Web SSH client works, or use your own client.
-
Edit
~/.bashrcin the container home directory. Add lines in the form:export VAR_NAME=value -
Either log out and back in, or apply immediately for the current session:
source ~/.bashrc echo $VAR_NAME
New bash sessions on this container now see the variable.
Through variables.conf — Java application servers
For Java application servers, values that should reach the JVM as -D flags belong in variables.conf. The path depends on the stack:
| Stack | Path |
|---|---|
| Tomcat, TomEE | /opt/tomcat/conf/variables.conf |
| Jetty | /opt/jetty/etc/variables.conf |
| Spring Boot | /opt/shared/conf/variables.conf |
| GlassFish | /opt/glassfish/glassfish/domains/domain1/config/variables.conf |
| Payara | /opt/payara/glassfish/domains/domain1/config/variables.conf |
| WildFly | /opt/wildfly/conf/variables.conf |
To edit:
-
Click Config on the application server node to open the configuration file manager.
-
Navigate to
variables.conffor your stack. -
Add
-Dentries, separated by spaces or one per line:-Dvar1=value1 -Dvar2=value2 -Dmy.var3=/my/value -
Save the file.
-
Restart the application server nodes for the JVM to pick up the new flags.
Some servers (GlassFish, Payara, WildFly) also expose an admin panel that can add JVM options and custom variables. Both paths end up writing to the same place.
In application code:
String var1 = System.getProperty("var1");
String var2 = System.getProperty("var2");
String var3 = System.getProperty("my.var3");