> ## Documentation Index
> Fetch the complete documentation index at: https://docs.quixa.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture and Data Flow

> Components of an on-premise Quixa installation, trust boundaries, ports, and exactly which data leaves your network (including AI).

# Architecture and Data Flow

An on-premise installation runs as Docker containers on one VM. Only the web app and the API are published; everything else stays on the internal Docker network.

```mermaid theme={null}
flowchart LR
    subgraph Users["Your network: users"]
        B[Browser]
    end
    subgraph VM["Quixa VM (Docker network quixa-network)"]
        FE["quixa-frontend<br/>web app :3002"]
        API["quixa-api<br/>.NET API :5001"]
        RES["quixa-resolver<br/>script sandbox (not published)"]
        DB[("quixa-db<br/>SQL Server (not published)")]
        MB["quixa-metabase<br/>reports :3003 (optional)"]
    end
    subgraph Targets["Your network: APIs under test"]
        T[Internal APIs]
    end
    subgraph External["Optional external services"]
        AI[AI provider or local model]
        IDP[Microsoft Entra ID]
        SIEM[Your SIEM]
    end
    B -- HTTPS via your reverse proxy --> FE
    B -- HTTPS via your reverse proxy --> API
    API -- quixa_app login, TLS --> DB
    MB -- quixa_reporting login (read-only) --> DB
    API -- RESOLVER_TOKEN --> RES
    API -- outbound guard --> T
    API -. only when AI is on .-> AI
    API -. only when Entra is configured .-> IDP
    API -. audit events, syslog/TLS .-> SIEM
```

## Ports

| Port | Component | Exposed to | Notes |
| :- | :- | :- | :- |
| 3002 | Web app | Users (behind your TLS reverse proxy) | Static app, no data |
| 5001 | API | Users (behind your TLS reverse proxy) | All data access, authenticated |
| 3003 | Metabase | Administrators (optional profile) | Reads with a read-only login |
| 1433 | SQL Server | Docker network only | Not published |
| 3004 | Script sandbox | Docker network only | Not published; requires the shared token |

## Trust boundaries

* **Users → API**: every endpoint requires a signed-in user unless explicitly public (sign-in, health). Access tokens live 15 minutes and are bound to a revocable session.
* **API → database**: the API uses `quixa_app`, which only has rights on the Quixa database (read, write, schema changes). `sa` is used once at installation by `quixa-db-init` and by the operator for backups.
* **API → APIs under test**: every connection goes through the outbound guard. Cloud metadata and link-local addresses are always blocked; loopback and the Docker network are blocked; private ranges are reachable only when listed by the operator (`OUTBOUND_ALLOWED_CIDR`) or, on single-customer installations, by a workspace administrator.
* **API → script sandbox**: JavaScript/TypeScript script nodes run in `isolated-vm` isolates (separate V8 heap, 64 MB memory limit, 10 s time limit, no Node.js APIs, no file system or network access).

## What leaves your network

| Data | Destination | When | How to prevent it |
| :- | :- | :- | :- |
| Requests defined in flows | Your APIs under test | When a flow runs | Outbound rules (Backoffice → Security & Audit) |
| AI prompts: your request text, the relevant flow nodes (names, methods, URLs, headers with secrets masked), spec excerpts | The AI provider you configured (or your local model) | Only when a user uses an AI feature and AI is on | Switch AI off for the installation (`AI_ENABLED=false`) or per workspace; or configure a local model endpoint |
| Sign-in requests | Microsoft Entra ID | Only when Entra sign-in is configured | Use LDAP or local accounts |
| Audit events | Your SIEM | Only when `SIEM_ENABLED=true` | — |
| Nothing else | — | — | No telemetry is sent from on-premise installations unless configured |

Secrets are removed from AI prompts before they are sent: header values and JSON fields named like credentials, bearer/basic tokens, JWTs and provider keys are replaced with `{{secret}}`. See [AI data handling](https://docs.quixa.io/security/ai-data-handling.md).

## Data at rest

| Data | Where | Protection |
| :- | :- | :- |
| Flows, collections, executions, audit log | SQL Server | TLS in transit; database files on your disk (use disk encryption) |
| Credentials (auth schemes), AI provider keys, IdP secrets, authenticator secrets | SQL Server | Encrypted with ASP.NET Data Protection (AES-256-CBC + HMAC) |
| Data Protection key ring | SQL Server | Optionally encrypted with your certificate or an Azure Key Vault key |
| Execution history | SQL Server | Credentials redacted before storage; deleted after the retention period (90 days by default) |
| Backups | `/opt/quixa/backups` | AES-256 encrypted with `backup.key`, SHA-256 checksum |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.