---
title: "Infrastructure"
description: "The Azure services, data flow, and deployment architecture behind TurboPentest - how requests, tool execution, and findings move through the system."
canonical: https://turbopentest.com/docs/architecture/infrastructure
source: "TurboPentest Docs"
---

# Infrastructure

TurboPentest runs on Microsoft Azure with enterprise-grade infrastructure. This page covers the services used and how data flows through the system.

## Azure Services

| Service | Purpose | Details |
|---------|---------|---------|
| App Service | Web application | Next.js 15, auto-scaling, custom domain |
| Container Instances | Tool execution | Up to 14 isolated tool containers per pentest |
| Blob Storage | Output storage | Tool results, PDF reports, attestation letters |
| Container Registry | Tool images | Pre-built images for all 14 security tools |
| Neon PostgreSQL | Database | Prisma ORM, serverless, connection pooling |

## Tool Resource Allocation

Each security tool runs in its own Azure Container Instance with dedicated resources:

| Tool | CPU | Memory | Timeout |
|------|-----|--------|---------|
| Port Scanner | 1 core | 1 GB | ~17 min |
| Server Audit | 0.5 core | 1 GB | 45 min |
| Web Scanner | 1 core | 3 GB | 120 min |
| Vuln Scanner | 1 core | 2 GB | 90 min |
| Security Checks | 0.5 core | 1 GB | ~17 min |
| TLS Analyzer | 0.5 core | 2 GB | 65 min |
| Sub Hunter | 0.25 core | 0.5 GB | 5 min |
| Web Probe | 0.25 core | 0.5 GB | 5 min |
| Enumerator | 0.5 core | 1 GB | 60 min |
| WAF Detect | 0.25 core | 0.5 GB | 2 min |
| Net Scanner | 2 cores | 12 GB | 160 min |
| Secret Scanner | 0.25 core | 0.5 GB | 10 min |
| Code Scanner | 1 core | 2 GB | 10 min |
| Dep Scanner | 1 core | 1 GB | 10 min |

## Paladin Phase 2 Analysis

After Phase 1 completes, the [Paladin](/docs/architecture/paladin) agent swarm runs on Azure Container Instances, powered by Anthropic's Claude API across a three-model tier:

| Role | Model |
|------|-------|
| Specialists / breadth agents | Claude Sonnet 4.6 |
| High-volume depth + verification agents | Claude Haiku 4.5 |
| Orchestration / synthesis | Claude Opus 4.7 |

The number of agents scales with the credit tier:

| Tier | Agents |
|------|--------|
| Recon | 1 (generalist) |
| Audit-Ready | 4 |
| Threat-Hunt | ~10 |
| Adversarial-Depth | ~20 |

Agents coordinate through a **blackboard** - a Redis-backed shared workspace (Upstash in production), scoped per scan, with a PostgreSQL `AgentActivity` fallback via circuit breaker. The blackboard drives the live SSE activity view. Anthropic API calls are made over TLS 1.3.

## Scope Protection

TurboPentest enforces target authorization at multiple layers to prevent any tool or AI agent from reaching unauthorized domains:

| Layer | Mechanism | Enforcement |
|-------|-----------|-------------|
| **Domain Verification** | DNS TXT record proof of ownership | No pentest can launch against an unverified domain |
| **AI Agent Scope Binding** | Authorized domain list injected into Paladin system prompt | AI agents reject findings on unauthorized domains |
| **DNS Guard** | DNS server that only resolves per-tool authorized domains | Network-level block: unauthorized domains return NXDOMAIN |
| **Container Isolation** | Each tool runs in its own ephemeral ACI with no shared state | No lateral movement between containers |

The DNS Guard is a lightweight Alpine + dnsmasq container. It receives the list of authorized domains for each tool (the target, the callback host, and tool-specific update endpoints) and only forwards DNS queries for those domains to upstream resolvers. All other domains return NXDOMAIN, preventing tools from reaching unauthorized targets even if misconfigured.

## Data Flow

1. **User submits target** - Domain is validated and ownership verified via DNS TXT record
2. **Pentest created** - Record stored in PostgreSQL with status "queued", then "scanning" once tools launch
3. **Containers launched** - Azure Container Instances spin up for each tool in two waves (web tools launch after Port Scanner discovers web targets)
4. **Tool execution** - Each container runs its tool against the target within its domain scope
5. **Results stored** - Tool output written to Azure Blob Storage
6. **Callbacks received** - Each container sends a completion webhook to the app
7. **Paladin multi-agent analysis** - Specialist AI agents read all tool outputs from Blob Storage, receive authorized domain list in their system prompt, and generate findings in parallel
8. **Report generated** - PDF and attestation created, stored in Blob Storage
9. **Continuity tracking** - Previous findings re-evaluated and tracked as new, confirmed, or retest_confirmed
10. **Attestation hashing** - Report and attestation are SHA-256 hashed and issued a public verification link. A daily job batches attestation hashes into a Merkle tree; on-chain anchoring to Base L2 is planned and not yet live
11. **User notified** - Email via Mailgun, Slack webhook, Jira ticket, HubSpot CRM sync

## Deployment

The application is deployed via GitHub Actions CI/CD:

1. Every push and pull request triggers: lint, content review, and the test suite (Vitest)
2. Pushes to the main branch run the production build (which also enforces TypeScript type checking) and auto-deploy to Azure App Service
3. Tool container images are maintained in Azure Container Registry
4. A scheduled cron job keeps tool images updated with latest CVE databases

## Data Retention

- Tool containers are destroyed immediately after completion
- Tool output blobs are retained for the lifetime of the pentest record
- Users can delete their pentests and all associated data at any time
- A cleanup cron job removes stale data from incomplete pentests