Visit Azul.com Support

Requirements

Table of Contents
Need help?
Schedule a consultation with an Azul performance expert.
Contact Us

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 PATH. Java 25 is recommended. Docker is not needed.

CPU and memory

The query engine’s memory budget is 16 GB by default (EVENTS_DB_READ_MEMORY_LIMIT), and it is a budget for buffers on top of which the JVM and the operating system need room. On a host with 16 GB of RAM, set the budget to 8GB. The engine uses as many worker threads as the JVM sees CPUs by default (EVENTS_DB_READ_THREADS). See Configuration Options.

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 (EVENTS_DB_MAX_TEMP_DIRECTORY_SIZE) while large reads run. Nothing is deleted on a schedule, so the dataset only grows.

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. HTTPS_PORT changes it.

5173

Inbound

Plain HTTP. With a keystore it redirects to HTTPS by default. With ALLOW_PLAIN_HTTP=true it serves the web interface and the API to your reverse proxy. PORT changes it.

9000

Inbound

The management interface: health checks and metrics. It has no authentication and listens on 127.0.0.1:9000 by default, which serves a Prometheus on the same host. For a Prometheus on another host, set MANAGEMENT_HOST to the interface it reaches and restrict the port with a firewall to your monitoring network. See Monitoring and Health.

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 (EVENTS_DB_PATH, events/events.duckdb), together with your migration waves. Your inventory, its runs, its tags, and its trends are all computed from it, so this is the history of your estate, not a cache of it. Must be on a persistent volume.

The application database

An embedded H2 database (APP_DB_PATH, db/) with tenants, accounts, memberships, Forwarder registrations with their keys and tags, the delivery ledger, quota counters, wave schedules, exclusion groups, audit entries, and API tokens. Small by design: it grows with the number of people, Forwarders, and decisions, never with the size of your fleet. Must be on a persistent volume.

The inbox

The sealed files Forwarders deliver (INBOX_DIR, inbox/). Deliveries are kept after their rows reach the dataset unless you set INBOX_RETAIN_AFTER_INGEST to false.

The vulnerability data

The vulnerability datasets for Security Exposure (VULN_DATA_DIR, vuln-data/): the active dataset and the previous one, while the database remembers which one is active. Set VULN_DATA_DIR explicitly. When it is unset, the datasets land beside the release directories, and a backup of /var/lib/ljvmi misses them.

The scratch directory

Where queries that do not fit in memory spill: tmp/ next to the DuckDB file (/var/lib/ljvmi/events/tmp), unless you set EVENTS_DB_TEMP_DIRECTORY. Emptied at every start, so it need not be backed up, but it needs free disk.

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.

Email

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.