Requisitos

Servidor de InfraWard

	Mínimo	Recomendado
Sistema operativo	Cualquier Linux x86 de 64 bits (`linux/amd64`) que ejecute Docker Engine. Las imágenes publicadas no están construidas para ARM.	Una versión LTS actual (Debian 13, Ubuntu 24.04 o posterior, RHEL 9 o posterior)
Motor de contenedores	Docker Engine 24 o posterior con el plugin Compose v2	La última versión estable de Docker Engine
CPU	2 vCPU	4 vCPU si escaneas muchas imágenes grandes
Memoria	4 GB	8 GB con más de una réplica del worker
Disco	20 GB libres	50 GB o más en SSD

En qué se va el espacio:

Caché de Trivy: unos 3 GB en data/worker, compartidos por todas las réplicas del worker.
Escaneo de imágenes: cada imagen se exporta a data/worker/scan mientras se analiza. Se aceptan imágenes de hasta 4 GiB (TRIVY_MAX_IMAGE_SIZE), así que deja al menos ese espacio libre.
Base de datos: crece con el número de assets, SBOM y snapshots. Una instalación de prueba con tres servidores y cuatro contenedores ocupa unos 200 MB.

En reposo, los siete contenedores usan unos 500 MB de RAM. El consumo sube durante los escaneos de imágenes grandes.

Red

Desde	Hacia	Puerto	Para qué
Navegadores de los usuarios	Proxy inverso delante de `web`	443	Interfaz web y API
Servidores gestionados	`INFRAWARD_PUBLIC_URL`	443	Descarga del script de alta (solo durante el alta)
Contenedores `worker` y `gateway`	Servidores gestionados	22 (o el puerto SSH que indiques)	Recolección, escaneos y terminal web
Contenedor `worker`	Internet	443	Base de datos de Trivy (`mirror.gcr.io`, `ghcr.io`), CISA KEV, FIRST EPSS, API de Cloudflare, RDAP

El worker necesita salida HTTPS directa para descargar los datos de vulnerabilidades. KEV_URL y EPSS_URL pueden apuntar a espejos propios o quedarse vacías para desactivar esas fuentes, pero la base de datos de Trivy siempre se descarga de sus registros públicos. Consulta Vulnerabilidades.

Los servidores que no pueden llegar a InfraWard (detrás de NAT o de una VPN sin ruta de vuelta) se pueden dar de alta con el modo de script embebido, que no necesita conexión del servidor a InfraWard. El worker, en cambio, siempre tiene que llegar al servidor por SSH.

Nombre de dominio y TLS

Fuera de localhost, InfraWard tiene que servirse por HTTPS:

La cookie de sesión usa el prefijo __Host- y la marca Secure, así que los navegadores la descartan por HTTP en cualquier host que no sea localhost.
En producción, la API no arranca si PUBLIC_URL no es https (salvo en direcciones de loopback).

Prepara un nombre DNS (por ejemplo infraward.example.com) y un proxy inverso que termine el TLS. Consulta HTTPS y proxy inverso.

Servidores gestionados

Requisito	Detalles
Linux con servidor OpenSSH	sshd debe incluir `/etc/ssh/sshd_config.d/*.conf` (lo normal en Debian, Ubuntu y RHEL 9 o posterior). El modo con certificados escribe ahí su configuración.
`sudo`	El usuario `inventory` ejecuta un único ayudante con `sudo -n`. Proxmox VE no trae `sudo`: marca Instalar sudo si falta al generar el comando y el script lo instala. Se admite `sudo-rs` (Ubuntu 25.10 y posteriores).
`python3`	Lo necesita Ansible para la recolección. Los CT de Proxmox también necesitan `python3` para inventariarse.
`bash` y `curl`	Para ejecutar el comando de alta. En el modo embebido, `base64` y `gunzip` en lugar de `curl`.
Reloj sincronizado	En el modo con certificados, el script se detiene si el reloj del servidor va más de 5 minutos atrasado. Usa NTP o `systemd-timesyncd`.
Acceso root una vez	El comando de alta se ejecuta como root. Después, InfraWard no vuelve a usar credenciales de root.

Navegador

Una versión actual de Chrome, Edge, Firefox o Safari. Si pruebas en http://localhost con Safari, consulta Solución de problemas.

Antes de seguir

Docker Engine y el plugin de Compose están instalados (docker compose version).
Tienes un nombre DNS y una forma de obtener un certificado TLS para él.
El servidor de InfraWard llega a tus servidores por su puerto SSH.
Tienes una app de autenticación para la verificación en dos pasos del administrador.

Siguiente: Instalar con Docker Compose.