Skip to Content

Scaling & Capacity Planning

Plan and configure resources based on your concurrent scanning requirements.

Understanding Resource Units

Kubernetes uses specific units for CPU and memory:

UnitMeaningEquivalent
m (millicores)CPU measurement1000m = 1 CPU core
Mi (mebibytes)Memory measurement1 Mi ≈ 1 MB
Gi (gibibytes)Memory measurement1 Gi ≈ 1 GB

For example, 200m CPU means 0.2 CPU cores (20% of one core), and 256Mi means approximately 256 MB of memory.

How Scanning Works

When a scan is triggered:

  1. Scan Scheduler receives the request and queues it in Redis
  2. Scan Manager picks up the job and creates an ephemeral Scan Worker pod
  3. For JavaScript-heavy applications, a Chrome Instance pod is also created
  4. Once the scan completes, the ephemeral pods are automatically cleaned up

Each scan-manager pod can handle 5 concurrent scans by default.

Key formula: scan_manager_replicas × 5 = max concurrent scans

Component Resources

Static Components (Always Running)

These components run continuously regardless of scan activity:

  • Scan Scheduler
  • Scan Manager
  • Chrome Controller
  • Redis

Dynamic Components (Per Active Scan)

These pods are created on-demand for each running scan:

  • Scan Worker
  • Chrome Instance

Capacity Planning Table

Use this table to plan resources based on your concurrent scan requirements:

Concurrent ScansScan Manager ReplicasScan Scheduler ReplicasChrome ControllerTotal CPUTotal Memory
5111~2 vCPU~8 Gi
10221~4 vCPU~16 Gi
20421~8 vCPU~32 Gi
501032~16 vCPU~64 Gi
1002032~32 vCPU~128 Gi

Total CPU/Memory = aggregate across all nodes. Your cluster’s node autoscaler distributes this across multiple nodes automatically.

Calculation formula:

  • Scan Manager replicas = ceil(concurrent_scans / 5)
  • Per scan memory (peak) = 1Gi (worker) + 3Gi (Chrome + shm) = 4Gi
  • Per scan CPU (peak) = 1 core (worker) + 1 core (Chrome) = 2 cores

No hard limit: There is no maximum concurrent scan limit enforced by the software. Scale as high as your cluster resources allow.

Node Autoscaling

Most managed Kubernetes services (EKS, AKS, GKE) support automatic node scaling. When enabled:

  1. Nodes are created on demand - When pods are scheduled, the autoscaler provisions nodes
  2. Right-sized instances - Selects appropriate instance types based on pod resource requests
  3. Horizontal scaling - Creates multiple smaller nodes rather than one large node
  4. Scale to zero - Terminates unused nodes when scans complete

You don’t need to pre-provision large nodes. The autoscaler handles it automatically.

Example: For 20 concurrent scans needing ~8 vCPU / ~32 Gi total, the autoscaler might create:

  • 4× small nodes (2 vCPU / 8 Gi each), or
  • 2× medium nodes (4 vCPU / 16 Gi each)

Configuring Replicas

Configure replica counts and autoscaling in your Terraform module or Helm chart values. See the Terraform module documentation or Helm chart documentation for available variables.

Next Steps

Last updated on