Visit Support

Configuration Options for CRS in JVM

Connected Runtime Services (CRS) is the component inside the JVM that runs your applications. CRS collects the dependency information of your application, and sends it via the Forwarder to Azul Vulnerability Detection.

Skip to section "Where to specify arguments" for a quick start.

Configuration Options

CRS can be controlled with the following command line arguments or environment variables.

Command line Environment Variable Options



  • auto: Default value. CRS decides whether it needs to start in the main method, and excludes tools like javap, javac having a specific main method in

  • on: Forces CRS to start, if all required configurations are available (e.g. endpoint), even for tools like javap, javac.

  • off: Forces CRS to be disabled regardless

When you add the -XX:AzCRSMode option to the command line, the enable option, presented in the AzCRSArguments command line option with the AZ_CRS_ARGUMENTS environment variable, is ignored.



See description below


See description below

CRS Arguments

CRS Arguments are specified in a comma-separated value format.

-XX:AzCRSArguments=expression1,expression2,expression3,... OR export AZ_CRS_ARGUMENTS=expression1,expression2,expression3,...

Each expression is either <propertyName>=<value>, or just <propertyName> for Boolean properties. These are the available properties:

Argument Default Description



Use this argument when you can’t adjust the command line, to enable or disable the CRS agent. Enabling the CRS agent with enable=true has the same effect as -XX:AzCRSMode=auto.

When you specify the -XX:AzCRSMode runtime flag, this enable environment variable flag, gets ignored.



Number of milliseconds to delay the CRS start. The default enables integration with major Java frameworks. Lower to 0 for short-lived microservices.



Number of milliseconds to hold a JVM alive at its end, providing time to send the collected data to the Forwarder. Raise the value to provide time to short-lived microservices. The provided value will be used as a maximum, if CRS takes less time (down to 0), the delay will not use the fully defined duration.



Enables the Code Inventory functionality at the method level. When set to true, it will send events of the first method execution to the Forwarder.



The level of logging for CRS. Options are (case insensitive): TRACE, DEBUG, INFO, WARNING, ERROR, OFF.

The use of the TRACE level is discouraged, since the size of the output will be enormous.



If set, this keystore will be used to authenticate the JVM with the Forwarder. Set this to a Java Keystore file if you are using self-signed certificates.



Location of a properties file to configure CRS.



This is the base URL of your Forwarder instance. If null, your runtime will perform a DNS-based lookup to locate its Forwarder. If no Forwarder is specified anywhere, CRS will be effectively disabled.

The Forwarder endpoint must be in URL format, e.g. https://FORWARDER_IP:443.



Print the value of all CRS arguments.



Number of seconds for your JVM to keep its long-lasting connection to the Forwarder open. Raising this may improve Java 11+ through its HTTP2 connections but may cause timeout/new connections with Java 8 HTTP 1.1.

CRS Tags

A tag is a user-defined key-value pair that is associated with an instance. Tags are used to search, categorize, and organize instances logically in the Azul Vulnerability Detection Web UI. Unlike instance IDs, tags are not unique. You can add the same tag to multiple instances as well as add multiple tags to one instance.

Applying Tags

Tag keys must begin with a letter. Both key and value may contain lower and upper case letters, and numbers. These additional characters are also allowed:

ALLOWED_KEY_EXTRA_CHARS = "-_." ALLOWED_VALUE_EXTRA_CHARS = "-_. :/@" <-- Includes space
Tags can be provided both as environment variable and in command line options. When using both, the result will be combined. It’s recommended to use environment variables as it allows AZ_CRS_ARGUMENTS to be mostly the same for each JVM.

Special Tags

A few tags are handled in a specific way with the system:

Tag Description Example


To use the "Code Inventory Summarization" feature, you need to configure an AppEnv value on the machine where you run the JVM. The value is, for example, the application name. This information is sent through the Forwarder to the Azul Vulnerability Detection system, together with information about the components, classes, and methods that are used.


Usage Examples

A few examples as command line argument or environment variable:"system-prop.tag_1=system prop/value@1; system_prop_tag.2=system prop:value/2" OR export CRS_TAGS="env.tag-1=value:1; env_Tag_2=value 2"

It is important that you properly tag your instances. As a general rule, tagging should reflect the way you categorize your Java applications. For example, you can use "west-coast", "east-coast", and so on to distinguish between different availability zones/locations.

Some instance properties are detected automatically. For example, you don’t have to tag Java versions, because it’s detected by CRS.

Where to Specify Arguments

To enable and configure your instances for CRS, you can choose to use one of these three options:

  1. JVM command line arguments

  2. The AZ_CRS_ARGUMENTS and CRS_TAGS environment variables

  3. A .properties file

The connected runtime looks for the configuration parameters in the order described above. You can use a combination of these options. If you set a parameter in several ways, for example via both the environment variable and configuration file, the JVM uses the value that comes first in the order given above.

In addition, the Forwarder address can be configured via DNS records. See Service discovery via DNS.

Command Line Arguments

Pass configuration parameters to the CRS (Connected Runtime Service) in the Azul JVM by using the -XX:AzCRSArguments command line argument:

Minimal command that sets the api.url parameter via JVM arguments.:
java -XX:AzCRSMode=on \ -XX:AzCRSArguments=api.url={forwarder_endpoint} \ MyApp
A more extended example via JVM arguments:
java -XX:AzCRSMode=on \ -XX:AzCRSArguments=api.url={forwarder_endpoint},log=DEBUG,delayTermination=120000,delayInitiation=0 \{tags} \ MyApp

Environment Variables

You can use dedicated environment variables to enable and control all JVM processes for Prime and Zulu Core distributions. When the environment variables are present, they will automatically apply to any newly started JVM, enabling CRS.

Substitute your forwarder_endpoint in the following example.

Starting with environment variables and optional arguments:
export CRS_TAGS={tags} export AZ_CRS_ARGUMENTS=enable,api.url={forwarder_endpoint},log=DEBUG,delayTermination=120000,delayInitiation=0 java MyApp

Properties File

A third way to set the CRS parameters is to use a local .properties file. There are two default locations where CRS looks for the properties file, and you can specify a custom properties file as a command line argument. CRS looks for the properties file in the following order:

  1. the file provided via the -XX:AzCRSArguments=props=/path/to/ argument

  2. ~/.az_crs/ in the user’s home directory

  3. $JRE/lib/, where $JRE is the directory where the JRE is located