Requirements

InfraWard host

	Minimum	Recommended
Operating system	Any 64-bit x86 Linux (linux/amd64) that runs Docker Engine. The published images are not built for ARM.	A current LTS release (Debian 13, Ubuntu 24.04 or later, RHEL 9 or later)
Container runtime	Docker Engine 24 or later with the Compose v2 plugin	The latest stable Docker Engine
CPU	2 vCPU	4 vCPU if you scan many large container images
Memory	4 GB	8 GB with more than one worker replica
Disk	20 GB free	50 GB or more on SSD

Where the space goes:

• Trivy cache: about 3 GB in data/worker, shared by all worker replicas.
• Image scans: each image is exported to data/worker/scan while it is scanned. Images up to 4 GiB are accepted (TRIVY_MAX_IMAGE_SIZE), so keep at least that much free.
• Database: grows with the number of assets, SBOMs and snapshots. A test install with three servers and four containers uses about 200 MB.

At rest, the seven containers use about 500 MB of RAM. Memory peaks during Trivy scans of large images.

Podman

InfraWard also runs with Podman and podman compose. Commands on these pages use docker compose; with Podman, replace it with podman compose and run init.sh as CONTAINER_ENGINE=podman ./init.sh. On hosts with SELinux enforcing (Fedora, RHEL), bind mounts may need the :Z option.

Network

From	To	Port	Purpose
Users’ browsers	Reverse proxy in front of web	443	Web interface and API
Managed servers	INFRAWARD_PUBLIC_URL	443	Download of the enrolment script (only while enrolling)
worker and gateway containers	Managed servers	22 (or the SSH port you set)	Collection, scans and the web terminal
worker container	Internet	443	Trivy database (mirror.gcr.io, ghcr.io), CISA KEV, FIRST EPSS, Cloudflare API, RDAP

The worker needs direct outbound HTTPS to download vulnerability data. KEV_URL and EPSS_URL can point to your own mirrors or be left empty to disable those sources, but the Trivy database is always downloaded from its public registries. See Vulnerabilities.

Servers that cannot reach InfraWard (behind NAT or a VPN without a route back) can still be enrolled with the embedded script mode, which needs no connection from the server to InfraWard. The worker must always be able to reach the server over SSH.

Domain name and TLS

Outside localhost, InfraWard must be served over HTTPS:

• The session cookie uses the __Host- prefix and the Secure flag, so browsers drop it over plain HTTP on any host other than localhost.
• In production the API refuses to start if PUBLIC_URL is not https (loopback addresses are the only exception).

Plan a DNS name (for example infraward.example.com) and a reverse proxy that terminates TLS. See HTTPS and reverse proxy.

Managed servers

Requirement	Details
Linux with OpenSSH server	sshd must include /etc/ssh/sshd_config.d/*.conf (the default on Debian, Ubuntu, RHEL 9 and later). Certificate mode writes its configuration there.
sudo	The inventory user runs a single helper through sudo -n. Proxmox VE does not ship sudo: tick Instalar sudo si falta (Install sudo if missing) when generating the command, and the script installs it. sudo-rs (Ubuntu 25.10 and later) is supported.
python3	Ansible needs it for collection. Proxmox CTs also need python3 to be inventoried.
bash and curl	To run the enrolment command. With the embedded mode, base64 and gunzip instead of curl.
Synchronised clock	In certificate mode the script stops if the server clock is more than 5 minutes behind. Use NTP or systemd-timesyncd.
Root access once	The enrolment command runs as root. After that, InfraWard never uses root credentials.

Browser

A current version of Chrome, Edge, Firefox or Safari. When testing on http://localhost with Safari, see Troubleshooting.

Before you continue

• Docker Engine and the Compose plugin are installed (docker compose version).
• You have a DNS name and a way to get a TLS certificate for it.
• The InfraWard host can reach your servers on their SSH port.
• You have an authenticator app for the administrator’s two-factor authentication.

Next: Install with Docker Compose.