Architecture
Microservices, worker fan-out, containerised scanners and deployment models.
ScanSuite is built on a highly scalable microservices architecture, ensuring modularity, flexibility, and efficient resource utilization. Each component operates independently within containerized environments, allowing seamless horizontal scaling based on workload demands.
Scanning tasks are distributed across a pool of worker nodes, enabling parallel execution for improved performance and fault tolerance. Each available worker dynamically retrieves a task and executes it by invoking one or more scanners running in isolated Docker containers. This architecture supports unlimited scalability in parallel scanning, optimizing execution speed and system stability.
Scan results are parsed, stored, and uploaded to DefectDojo, enabling centralized vulnerability management. Scan reports are also available for download and review as needed.
ScanSuite supports integration with external infrastructure scanners, enabling organizations to consolidate and manage all security scans from a unified ScanSuite console. This provides a single pane of glass for security teams to oversee scan operations efficiently.
Deployment topology
Server components can be deployed in cloud, on-premises, or hybrid environments, offering flexibility to adapt to various infrastructure needs. The following diagram illustrates an example deployment of ScanSuite's architecture:
Here both ScanSuite and DefectDojo are deployed on a single server (Server 1), while external scanners are installed on remote servers (Server 2 and Server 3 in the diagram) and reachable by Server 1 over HTTPS.
It is generally possible to install ScanSuite and DefectDojo on separate servers, ensuring the latter is also reachable by ScanSuite over HTTPS.
For production purposes it is recommended to set up a separate PostgreSQL cluster and point both ScanSuite and DefectDojo to the respective instances, as described in the Administration section.
Platform services
A single-host installation brings up the following containers. Understanding which is which makes the log commands in Troubleshooting easier to follow.
| Service | Responsibility |
|---|---|
| web | The Flask web application and REST endpoints that serve the console. |
| worker | Executes scans: runs scanner containers, parses output, persists findings. Scale this with the worker count when starting ScanSuite. |
| worker_admin | Orchestration. Creates and cancels scan jobs, stops containers, and dispatches static and dynamic work to the scan workers. |
| celery_beat | The scheduler behind saved scans — daily, weekly and monthly runs, monitored branches and incremental scans. |
| postgres | Primary datastore for products, scans, assets, credentials and vulnerabilities. |
| redis | Message broker and result backend for the task queues. |
| object storage | Stores scan artefacts and reports outside the database. |
| nginx | TLS termination and reverse proxy in front of the console. |
Scan execution is deliberately split from orchestration. Long-running scans never occupy a web request, which is why the console stays responsive while an engagement runs for hours.
Last reviewed 2026-08-15