Home › Docs ›Operations › Single-Host Deployment

Single-Host Deployment

Run the edge and SIEM stacks on one host for evaluation

A single host runs the full lifecycle: proxy, detection, honeypot pools, Suricata, Redis, Elasticsearch and Kibana. It is the simplest way to evaluate the system and the right shape for a lab, but the resource math changes: every pool and the SIEM compete for the same memory and CPU.

Simple One compose target Start both stacks on one machine and keep all state local. No mTLS channel or remote SSH target is required. Lab friendly

Careful Shared resources Lower POOL_MAX_MEMORY_MB and POOL_MAX_CPUS, and watch the free-memory floor before enabling many pools. Budget first

Known limit Same test caveat Loopback traffic can make Suricata attribute alerts to container-internal addresses, so IP reputation may not fire locally. is_private_ip()

SIEM Single-Host Context

On one host there is a single SIEM instance that holds all six Kibana dashboards and handles their full lifecycle, relying on build_dashboards.py for creation and export_dashboards.py for distribution and backup. Certificate generation still runs, but the Vector agent connects over host.docker.internal rather than a remote IP — the vector server certificate's Subject Alternative Name list already covers both cases (see Transport & mTLS).

Tip: the database layer is lighter

If the host is memory-constrained, consider the database honeypot layer (docker-compose.db-proxy.yml): it runs one eshop and swaps only the database per request, so there are no separate decoy backends to build or hold in memory — at the cost of not isolating file-upload or RCE attacks. The reverse-proxy layer remains the default when those attack classes matter.

Single-Host Notes

Simplifies deployment by running honeypot, detection, and SIEM components on one host.
Suitable for evaluation, lab environments, and small-scale deployments.
May require additional tuning for resource constraints and performance.

In a single-host deployment, all components (reverse proxy, Nginx Lua pipeline, Suricata, Kibana/Elasticsearch, Redis) run on the same host. The routing pipeline diverts suspicious traffic to local honeypot pools, while security events are logged locally and visualized via Kibana on the same host.

Resource Budgeting

Set the pool ceiling first. POOL_MAX and POOL_MAX_MEMORY_MB are the two knobs that keep one busy session from starving Elasticsearch.
Measure, then lower the reservation. The pool test measured roughly 430 MB per pool near idle while the default budget charges 1536 MB. Lower POOL_RESERVE_MEM_MB only after confirming a pool behaves on your host.
Keep the free-memory floor. POOL_MIN_FREE_MEM_MB, load and disk guards are the last line of defence; do not disable them to squeeze in one more pool.
Expect slower builds. With POOL_PARALLEL_BUILDS at 2 and the SIEM sharing the CPU, a fresh pool takes longer to become ready.
Treat loopback as a test artefact. Suricata's source address may be container-internal, so validate the network path on a real external request before tuning reputation thresholds.