Deployment · self-hosted

What your server needs, before you buy.

Defensse installs on one Linux server you control — your data never leaves it. Below is the honest hardware bill: what the platform actually consumes, what each plan needs, and how the box grows with the number of endpoints you monitor.

Linux only · x86-64 · Docker Compose · no Windows Server build
Footprint

What actually runs on the box.

Defensse is a Docker Compose stack. Which containers start depends on your plan — and the memory each group holds is the reason the numbers below look the way they do.

Core GRC

Every plan

~0.4 GB resident memory
  • django · app + api
  • postgresql
  • redis
  • nginx
  • minio · evidence
  • scheduler
SOC · Wazuh

Professional and up

~3.8 GB resident memory
  • wazuh.indexer
  • wazuh.manager
  • wazuh.dashboard
Threat intel · OpenCTI

Professional and up

~4.5 GB resident memory
  • elasticsearch
  • opencti platform
  • worker · rabbitmq
  • redis · minio
  • 4 feed connectors
Identity · Keycloak

Enterprise

~0.8 GB resident memory
  • keycloak · sso/mfa
  • saml to wazuh
  • oidc to opencti
AI Assistant · Hermes

Enterprise + AI

≤ 2.5 GB container memory limits
  • hermes agent
  • ai-tools · tools + relay
  • model runs in the cloud · no GPU

These are measured figures, not estimates — taken from a live Defensse installation running the full stack. The complete platform idles at roughly 9.5 GB. Your sizing target is that number plus room for the alert volume your endpoints produce.

By plan

Minimum server, plan by plan.

Starter runs the GRC platform alone and is comfortable on a small VPS. The moment the SOC comes on, the search engines set the floor.

Starter

GRC modules only — no SOC, no agents
vCPU
2 cores
Memory
4 GB8 GB recommended
Disk
60 GB SSDevidence and attachments grow this
Monitored endpoints
—agents ship with the SOC
A €5–10/month VPS is genuinely enough here.

Enterprise

Everything, plus Keycloak SSO and AI governance
vCPU
8–24 coresscales with endpoint count
Memory
24–64 GBscales with endpoint count
Disk
500 GB – 4 TB NVMedriven by retention, see below
Monitored endpoints
10 → 250+sized per the table below
The table below is the one that matters for Enterprise. Enterprise + AI adds up to 2.5 GB of memory and needs outbound HTTPS to our license server.
Enterprise sizing

Size the server by how many endpoints you monitor.

One agent runs on each Linux server you want watched. Agents are cheap on the endpoint and expensive on the collector — every one of them adds events to index and keep. Pick the row that matches your fleet.

Linux endpoints vCPU Memory Disk (365-day retention) Indexer heap Topology
Up to 10 8 cores 16 GB 250 GB NVMe 1 GB Single server. The default install, unchanged.
Up to 30 8 cores 24 GB 500 GB NVMe 2 GB Single server. Raise the indexer heap at install time.
Up to 50 12 cores 32 GB 1 TB NVMe 4 GB Single server. Put the indexer data on its own volume.
Up to 100 16 cores 48 GB 2 TB NVMe 8 GB Single server, but a dedicated data disk is now required, not advisory.
100 – 250 24 cores 64 GB 4 TB NVMe 16 GB Two servers: the Wazuh indexer moves to its own node, the platform keeps the first.
250 + — — — — Multi-node indexer cluster and a second Wazuh manager. We size this with you — get in touch.
Why memory climbs firstThe Wazuh indexer and Elasticsearch are JVM search engines. They want heap for the shards they hold open, and the JVM never gives it back.
Why the disk is NVMeIndexing is a write-amplified workload with periodic force-merges. Spinning disks and network storage below ~3,000 IOPS will fall behind and alerts start queueing.
Never more than halfKeep every JVM heap at or below half the server's RAM, and never above 32 GB — past that the JVM loses compressed pointers and gets slower, not faster.
Storage

The disk number, worked out.

Disk is the only line that keeps growing after install, so it is worth understanding rather than trusting. Here is the arithmetic behind the table.

  • HotNew alerts are indexed and searchable. The index rolls over at 25 GB or 7 days, whichever comes first.
  • Warm · 30dReplicas dropped and segments force-merged. Still searchable, roughly 30% smaller.
  • Delete · 365dRemoved automatically. One year is the default because that is what most frameworks ask for — it is a policy setting, and shortening it shrinks every disk figure above proportionally.
# disk = platform baseline + indexed alerts
baseline 60 GB images, CTI feeds, DB, evidence
per endpoint 15 MB indexed alerts per day
retention 365 d default ISM policy
# so, per endpoint, per year:
15 MB x 365 = ~5.4 GB
# 50 endpoints:
60 + (50 x 5.4) = ~330 GB → 1 TB provisioned
# 15 MB/day is a busy production server.
# A quiet one measures closer to 3-4 MB/day.
# The table provisions for the busy case.
Operating system

Linux, 64-bit, with Docker.

Anything that runs a current Docker Engine will work. These are the distributions the installer is tested against.

Tested distributions

Pick any of these

Debian 12Debian 13 Ubuntu 22.04 LTSUbuntu 24.04 LTS RHEL 9Rocky Linux 9AlmaLinux 9

Other modern distributions with Docker Engine 24+ are expected to work, they are simply not part of the release test matrix.

Prerequisites

What the installer expects

  • architecturex86-64 (amd64). ARM is not supported — the SOC images are not published for it.
  • kernel5.10 or newer, 64-bit
  • dockerEngine 24+ with Compose v2. The installer will fetch it if missing.
  • toolsgit, curl, openssl
  • accessroot, or a user with sudo
  • sysctlvm.max_map_count=262144 — set for you at install; both search engines refuse to start below it
  • swapDisabled, or the JVM heaps will page and searches will crawl
Network

Ports to open.

Nothing beyond the web ports has to face the public internet — the agent ports only need to be reachable from the endpoints you monitor.

Inbound

To the Defensse server

  • 80 / tcpHTTP — redirects to HTTPS
  • 443 / tcpThe platform, the dashboards, the API
  • 1514 / tcpAgent events — from monitored endpoints only
  • 1515 / tcpAgent enrolment — from monitored endpoints only
  • 514 / udpSyslog ingestion — optional, for network gear
Outbound

From the Defensse server

  • 443 / tcpContainer images at install and upgrade time
  • 443 / tcpWazuh agent packages, for the endpoints to install from
  • 443 / tcpThreat intelligence feeds — MITRE ATT&CK, CVE, URLhaus, AlienVault OTX
  • 443 / tcpLicence check-in

Fully air-gapped installs are possible with a local registry and mirrored feeds — that is an Enterprise deployment, arranged with us.

Monitored endpoints

What an agent costs the machine it watches.

Almost nothing. The agent collects and ships — the analysis all happens on the Defensse server, which is why that server is the one you size carefully.

Per endpoint

Agent footprint

  • memory~35 MB resident
  • cpuUnder 1% at idle; brief spikes during scheduled integrity scans
  • disk~50 MB installed, plus a small local queue
  • installOne command, pasted on the endpoint — apt and yum/dnf both handled

Linux for the server. Either, for the endpoints.

The Defensse server itself is Linux-only. There is no Windows Server build and one is not planned — the platform ships as a Linux container stack, and the search engines it depends on are only supported that way. Running it under WSL or a Windows Docker Desktop host is not supported either.

The machines you monitor are a separate question. Agents install on Linux and Windows endpoints alike, and both report into the same console. The sizing table above counts Linux endpoints; a Windows endpoint typically produces two to three times the event volume, so count each one as roughly three when you read the table.

Not sure which row you are

Tell us your fleet, we will size the box.

Send us how many servers you need watched and which framework you report against. You will get a concrete spec, and a price, within one business day.