Requirements
Check the following before you start the installation of Azul Intelligence On-Premises.
Host
| Item | Requirement |
|---|---|
Operating system |
Linux, with Java 21 or newer on the |
CPU and memory |
The query engine’s memory budget is 16 GB by default ( |
Disk |
Room for the observation dataset, which grows with the number of JVMs in your estate and with how long the installation has been running, and for the inbox, which keeps delivered files by default. Add room for the query spill directory, which can use up to 24 GB ( |
For the supported operating systems and the sizing per estate size, see the System Requirements. The Small, Medium, and Large sizes are verified on this release, and the XL size is provisional.
Network ports
| Port | Direction | Purpose |
|---|---|---|
8443 |
Inbound |
HTTPS for the web interface and the API, when the installation serves TLS from a keystore. Your Forwarders and your users reach the application here. |
5173 |
Inbound |
Plain HTTP. With a keystore it redirects to HTTPS by default. With |
9000 |
Inbound |
The management interface: health checks and metrics. It has no authentication and listens on |
Forwarders connect outbound to the application, and they connect to your object store when you run the S3 backend. Your installation connects outbound only to the services you configure for it: the mail relay, the object store, and, when you set VULN_DATA_METADATA_URL, the host serving the vulnerability dataset. With none of these configured, it opens no outbound connection.
-
Metrics are scraped, never pushed, so an installation with all outbound access blocked stays fully observable.
-
Security Exposure needs a vulnerability dataset. You can upload it in the web interface or copy it into a folder, which needs no outbound access. The optional automatic download is the one connection to a public host, and it uses HTTPS only. See Vulnerability data.
-
The Forwarder list flags a version that has been reporting for 90 days or longer. That check is local, so it works the same on an isolated network.
HTTPS
The installation requires HTTPS. It does not start until you choose one of two setups:
-
Direct TLS, the recommended setup. You provide a keystore (JKS or PKCS12) with a certificate from your internal CA, and the installation serves HTTPS on port 8443. The installation never generates or signs a certificate itself, so the certificate must be one your browsers and the Java runtime of every Forwarder host already trust.
-
TLS terminated by your reverse proxy. You set
ALLOW_PLAIN_HTTP=true, and the application serves plain HTTP behind your proxy, which handles the certificate. This is a deliberate opt-out, and the application logs a warning about it at every start.
Forwarders reach the installation at its https:// address. A Forwarder doesn’t follow redirects, so don’t give it the plain HTTP address of an installation that redirects to HTTPS.
Without HTTPS, observations and the Forwarder access key, which is the whole credential, travel your network unencrypted. Whoever captures the key can deliver data that your installation ingests as inventory.
See HTTPS and Sessions for the settings, and Choosing HTTP or HTTPS for the Forwarder side.
Storage
The application keeps its data in four directories, set by APP_DB_PATH, EVENTS_DB_PATH, INBOX_DIR, and VULN_DATA_DIR, plus a scratch directory. The examples in this documentation put all of them under /var/lib/ljvmi (db/, events/, inbox/, and vuln-data/). Plan a location and a backup for /var/lib/ljvmi before you install, and read Backup and Restore before you go live.
| Location | What it holds |
|---|---|
The observation dataset |
Every observation your estate has ever delivered, in one native DuckDB file ( |
The application database |
An embedded H2 database ( |
The inbox |
The sealed files Forwarders deliver ( |
The vulnerability data |
The vulnerability datasets for Security Exposure ( |
The scratch directory |
Where queries that do not fit in memory spill: |
The inbox runs on either of two backends, and your installation tells each Forwarder which one to use at check-in, so the two ends cannot disagree about it:
-
A local filesystem directory. A delivery becomes visible by an atomic rename, so the reader never sees a partial file. Each Forwarder writes into this directory itself, so every Forwarder host needs it, writable: on the same host, or as a network share or container volume. See Storing in a Directory.
-
An S3-compatible bucket, which also covers self-hosted stores such as Silo, RustFS, and Ceph. Your installation never creates the bucket, and a Forwarder holds no bucket credentials of its own: it receives a short-lived, prefix-scoped upload grant with each check-in and status poll.
The bucket grant is also how revocation takes effect on that backend. A Forwarder you disable keeps write access until its current grant expires, 15 minutes by default, and is issued no new one.
See Storage Locations for the settings.
Invitations, password resets, and quota notices arrive by email when you configure a mail transport in the deployment environment, and an Admin selects it under Settings > Email. A deployment without one stays fully functional: Admins share one-time links by hand, and the notices appear in the web interface either way.
You need a relay that supports STARTTLS with a certificate your installation trusts, a From address, and the public address of your installation in LJVMI_WEB_PUBLIC_BASE_URL. See Email and the public address for the variables, and Email.