.png){kind=logo}
Single-Node deployment technical reference detailing components and network traffic flow.
Overview
In a single-node deployment, all AgileSec components run on a single server or virtual machine. This topology is primarily intended for development, testing, and proof-of-concept environments where simplicity is preferred over horizontal scale and high availability.
Component placement
All AgileSec components are co-located on the same host.
Because all components run on a single host, most internal service-to-service and datastore traffic stays local. This reduces networking complexity and minimizes the external firewall surface area.
The following services are installed and run on single nodes:
|
Component |
Category |
Description |
|---|---|---|
|
OpenSearch |
Datastores / messaging |
Indexes and stores findings data received from sensors. |
|
OpenSearch Dashboards |
User-facing services |
Self-service tool to perform advanced searches, create custom visualizations, and build tailored reports for findings. |
|
MongoDB |
Datastores / messaging |
Stores operational and configuration data for the platform. |
|
Kafka |
Datastores / messaging |
Central communication backbone for the platform. Carries job requests, execution events, raw findings, processed findings, control messages, and system events for asynchronous processing across platform. |
|
Ingestion Service |
Platform services |
Always-on ingestion endpoint for receiving data streams from sensors. Publishes data to the Kafka pipeline for further processing. |
|
Manager Service |
Platform services |
Always-on service responsible for job lifecycle management and post-scan orchestration. |
|
Scheduler Service |
Platform services; Scan execution |
Always-on orchestration service responsible for initiating jobs. Executes scans locally on the same node (when scans are run on the platform). |
|
Secrets Management Service |
Platform services |
Always-on service responsible for secure key management, token generation and encryption across the platform. |
|
Indexing Service |
Platform services |
Always-on service that consumes raw findings events from Kafka, performs schema validation, applies transformations, and indexes them into the OpenSearch Findings Datastore. |
|
FluentD Deprecated unless v2_sensors are enabled. |
v2 sensors backwards compatibility |
This service is deprecated. It is only used when |
|
Web UI |
User-facing services |
External web interface for the platform. |
|
Web API |
User-facing services |
API services for supporting Web UI. |
|
CBOM Exporter |
Platform services |
Handles CBOM export jobs. |
|
HAProxy |
Ingress / routing |
Internal load balancer and reverse proxy for routing traffic for all services. |
Network traffic flow
Single-node traffic can be understood as one external ingress point (terminated by HA Proxy) plus optional outbound scan traffic. In single-node mode, all internal services and datastores run locally on the same host, and east-west traffic stays on the host network.
External ingress (UI / APIs / Dashboards)
-
Browser / API client → HA Proxy (HTTPS)
-
HA Proxy routes traffic to the appropriate internal service, for example:
-
Web UI (user interface)
-
Web API (Scan API requests for scan setup/execution/status)
-
OpenSearch Dashboards
-
OpenSearch (Search API requests; currently routed directly to OpenSearch)
-
-
Web UI interactions call the Web API through the same external endpoint.
-
OpenSearch Dashboards queries OpenSearch internally.
External ingress (remote sensors → Ingestion only)
-
Remote sensor → HA Proxy (HTTPS)
-
HA Proxy → Ingestion service
-
Ingestion persists and/or forwards scan events/results into the platform pipeline.
Scan execution and outbound scan egress (when scans run on the platform)
-
A scan can be initiated either from the Platform UI (on-demand or scheduled) or through the Scan API. In all cases, the Scheduler is responsible for executing the scan.
-
A scan request is created via the Platform UI (on-demand or scheduled) or via the Scan API (Web API).
-
The Scheduler executes the scan locally on the node.
-
The scan initiates outbound connections to target systems (for example: source code repositories, cloud APIs, databases, or hosts).
-
Scan results and events are submitted to Ingestion and persisted through the platform pipeline.
In single-node deployments, the same host processes user/API requests, ingest pipelines, datastore IO, and (optionally) scan workloads, so sizing should account for peak scan activity and indexing throughput.