Architecture

What a ScanSuite Teams installation runs and how it can be deployed. Three deployment models exist: a single server, which runs every scan type, and Google Cloud or Azure, which run the static analyses on managed services. Where a server keeps its data and which network flows it needs are in Administration.

On a server

zoom_inEnlarge

The installer puts everything in /opt/scansuite and runs it with Docker Compose. Every service is a container; ./scansuite status lists them and ./scansuite logs <service> shows the log of one. The web, worker and scheduler containers restart by themselves after a crash.

Capacity

Each scan worker runs one scan at a time, so a default installation runs two scans in parallel and queues the rest. ./scansuite restart <n> starts n workers (1 to 100); size the host for them as Technical Requirements describes. The count applies until the next start without one: the boot service starts two again after a reboot.

On Google Cloud

The console and workers run on Cloud Run (or GKE, with platform = "gke"), with Cloud SQL for PostgreSQL, Memorystore for Redis, Cloud Storage for scan artefacts, Secret Manager for passwords and Artifact Registry for the images. Each scan runs as its own Cloud Run job. There is no Docker daemon, so this deployment runs the static analyses; Vertex AI or any OpenAI-compatible endpoint is the AI provider.

zoom_inEnlarge

What gets built, and how to deploy it: Install on Google Cloud.

On Microsoft Azure

The console and workers run on Azure Container Apps, with Azure Database for PostgreSQL, Blob Storage, Key Vault and the deployment's own Container Registry, all in one resource group. Each scan runs as its own Container Apps job. As on Google Cloud, this deployment runs the static analyses; Azure OpenAI or any other OpenAI-compatible endpoint is the AI provider.

zoom_inEnlarge

What gets built, and how to deploy it: Install on Microsoft Azure.

Which one to choose