What is Azul Intelligence On-Premises
Azul Intelligence On-Premises is installed and run inside your own infrastructure, with every record your estate produces kept on systems you control. By default no component needs access to the public internet: the only outbound connection is the optional download of vulnerability data, which an Operator turns on by setting VULN_DATA_METADATA_URL. See Security Exposure.
Capabilities arrive in it as features. The first available feature is JVM Inventory, and it is what this documentation describes today. As further features join the platform, the installation, administration, and data-delivery pages stay the same, and each feature adds its own pages.
flowchart LR
subgraph yours["Your infrastructure"]
direction LR
agent["JVMs + Agent"]
amt["AMT scans"]
fwd["Forwarder"]
inbox[("Inbox (filesystem or S3)")]
subgraph app["Azul Intelligence On-Premises"]
direction LR
ui["Web UI and Public API"]
store[("Event store (embedded DB)")]
ui --- store
end
agent --> fwd
amt --> fwd
fwd --> inbox
inbox --> app
end
JVM Inventory
Java spreads through an organization faster than anyone documents it. It arrives bundled with an application, inside a vendor appliance, or on a host that someone provisioned years ago. At scale, nobody can say what Java runs, where it runs, or what it does.
JVM Inventory answers those three questions. It collects what your JVMs report as they run, folds every observation into one record per machine that lists every installation it holds, and turns the result into an estate you can filter, chart, and act on. Managing Java at scale starts with knowing what you have.
What You Get
The platform provides:
-
A multi-user tenant: Admins invite and manage members, register data sources, and read an audit log of who did what. See Users and Roles.
-
An integration API: a versioned REST surface for automation at fleet scale, with a console you can try calls from. See The Integration API.
The JVM Inventory feature provides:
-
Fleet Inventory: one correlated, filterable record per machine, listing every JVM installation on it, built from both Azul IC Agent and Azul Migration Toolkit (AMT) observations. See Fleet Inventory.
-
Trends: how your estate moves over time, by fleet size, vendor mix, and new machines found. See Trends.
-
Licensing Alerts: Coverage of your estate by vendor, Java release, and license, exclusion groups for installations that are known and stay, and migration waves. A wave counts the machines it was created for, is watched for a set number of days, and then records its outcome once: successful, unsuccessful, or unresolved. See Licensing Alerts.
-
Security Exposure: every installation seen in the last 30 days judged against the latest quarterly security update and the CISA Known Exploited Vulnerabilities catalog, with a recipe for moving to a recommended Azul build. See Security Exposure.
How It Fits Together
Intelligence On-Premises, with JVM Inventory as its first feature, runs as a single application on a host you control: one process serving both the web interface and the API, with an embedded database and an embedded query engine beside it. It bundles its own Azul Zulu JDK, so the Java version installed on the host does not matter, and it needs no Kafka, no external database, and no separate query cluster.
Getting data to it takes two stages, and you do the first one once.
A Forwarder in on-premises mode collects everything from one network location and delivers it to your installation. You deploy one Forwarder per location, never one per source type. The same Forwarder accepts every Agent and every AMT scan in that location, over one connection and one access key, so your Forwarder count stays in the handful even when your host count does not.
Behind each Forwarder sit as many sources as that location has hosts, of two kinds:
-
The Azul Migration Toolkit (AMT) scans a host and reports the Java it finds on disk. Static detection: which runtimes exist, including one that nobody has started in years.
-
The Azul IC Agent runs inside a JVM and reports it as it runs. Dynamic detection: which runtimes your organization actually uses, and which applications they carry.
AMT tells you what Java you have. The Agent tells you what Java you use. The gap between those two answers is where an unused installation shows up.
The Path One Observation Travels
-
An Agent or an AMT scan observes a JVM installation and hands the observation to the Forwarder serving its network location.
-
The Forwarder batches observations and writes them as sealed files into the storage your installation names for it: a directory on the host, or an S3-compatible bucket. Delivery doesn’t go through your installation, so with filesystem storage, an installation you cannot reach for an hour costs you no data. With S3 storage, the outage must stay shorter than the upload grant lifetime, 15 minutes by default.
-
Your installation reads the sealed files on a schedule, flattens them into its observation dataset, and derives the license of each observation as it goes.
-
Each delivery updates the inventory, its tags, and its trends in the same transaction that writes its observations, so no figure on a screen can fall out of step with the observations behind it.
Who Does What
Three roles divide the work.
| Role | Responsibility |
|---|---|
Operator |
Installs, upgrades, backs up, and monitors the deployment. Works on the host and in the configuration file, not in the web interface. The Operator decides where data lives, which storage backend the Forwarders write to, whether TLS terminates in front of the application or inside it, and who can reach the metrics port. HTTPS is required: the application either serves it from a keystore ( |
Admin |
Administers a tenant in the web interface: users and roles, data sources and their tags, exclusion groups, the vulnerability data, the email provider, API tokens, and the audit log. |
Member |
Uses every licensed capability, including decisions that carry commercial weight, such as creating a migration wave. Members have no access to the audit log, because its entries expose what other users did. |
The split between Operator and Admin is worth reading twice, because email crosses it. The Operator sets the transport (the SMTP relay address, sender, and credentials) and the public address of the installation in /etc/ljvmi/ljvmi.env. An Admin then selects the provider in the web interface, sends a test, and edits the message texts. See Email.
Where to Go Next
Start with Requirements, then install the application. After that, review the configuration options and connect your data sources.
Once your first data arrives, The Web Interface is the tour, and Fleet Inventory is where most of the work happens.
The pages on upgrading, backup and restore, and monitoring cover keeping the installation healthy.