Settings

Open Settings under Configure to view and edit supported, non-secret engine runtime controls. The page shows the configured value, its source, its accepted range, and whether that value is live or needs an engine container recreation.

Available controls

Setting	Applies	Purpose
Engine worker slots	Live	Aggregate capacity shared by scan workflow and post-processing jobs. Set it to 0 to pause pickup of new work.
Concurrent scan pool	Live	Maximum number of immediately started scans admitted at once. Queued scans wait until the active pool is empty.
Workers per scan	Live	Hard cap on worker slots used by one scan. Set it to 0 for automatic fair sharing.
Autoscale on provider capacity	Live	Reduces a scan's future worker cap after the provider reports server-capacity throttling. It does not change account quota limits.
Workspace setup concurrency	Engine recreation	Limits simultaneous checkout and isolated workspace preparation.
Model-call retries	Live	Additional attempts for retryable workflow-step and post-script model calls.
Model-call timeout	Live	Maximum duration of each future harness invocation.

Live changes affect future work; already-running model calls keep the values they started with. In the bundled Docker Compose deployment, settings are also written to the project .env file so a future docker compose up recreation keeps them.

Note

docker compose restart does not reload values from .env. After changing workspace setup concurrency, recreate the engine with docker compose up -d --force-recreate engine.

Warning

Raising worker or setup concurrency can exhaust provider rate limits, Docker networking, CPU, memory, or disk capacity. The UI asks for confirmation before pausing work or raising worker slots above the conservative recommendation.

Scheduling behavior

Engine worker slots are shared execution capacity. The concurrent scan pool controls how many scans can share that capacity, while workers per scan prevents one scan from taking every slot. With automatic sharing, active scans receive a fair portion of the available workers.

Queued scans remain separate from that pool: they start only after active scans finish. Automatic resume of an entire failed scan remains intentionally unavailable.

Model-call retries do not automatically resume a scan after it reaches the failed state. A failed scan still uses the manual Resume action. Temporary provider limits use the separate rate_limited state and retry automatically.

Secrets

Settings returns only an explicit allowlist of numeric runtime values. Provider API keys and login credentials are managed separately under Accounts and are never included in the settings response.