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

# Architecture and data flow

> Understand the workloads, supporting services, and network connections of a self-hosted Vidoc deployment.

A self-hosted deployment runs the Vidoc application and scan workloads in your Kubernetes infrastructure. Supporting data services and connections to your source code platform, identity provider, and LLM service complete the deployment.

The diagram shows the reference arrangement. Services outside the Kubernetes box can still be inside your internal network; their placement in the diagram does not require an internet connection. Vidoc reviews service placement and the network boundary with your team before installation. Refer to [Private network access](/deployment/networking#private-network-access).

```mermaid theme={null}
flowchart TB
    USERS[Users and CI runners] --> ENTRY[Web app and API]
    SCM[Source code platform] -->|Webhooks| ENTRY
    ENTRY -->|Repository access and PR results| SCM
    ENTRY -->|Sign-in| IDP[Your identity provider]

    subgraph K8S[Your Kubernetes infrastructure]
        ENTRY
        WORKERS[Scan workers]
        SANDBOX[Scan sandboxes]
        SERVICES[Workflow and data services]
        ENTRY --> SERVICES
        WORKERS --> SERVICES
        WORKERS --> SANDBOX
    end

    WORKERS -->|Read repository content| SCM
    WORKERS -->|Model requests| LLM[Your configured LLM service]
```

## Application workloads

| Component      | Role                                                                                                            |
| -------------- | --------------------------------------------------------------------------------------------------------------- |
| Web            | The user interface and its server-side functions, including sign-in and project administration.                 |
| API            | REST requests from the CLI and other clients, and webhook events from source code platforms.                    |
| Workers        | Background work, including repository processing and security scans.                                            |
| Scan sandboxes | Workspaces used by agents to inspect source code. The reference deployment uses OpenSandbox in the cluster.     |
| Migration jobs | Database changes required by the application release. These jobs are part of installation and upgrade planning. |

Workers and scan sandboxes need capacity in addition to the web and API services. Concurrent scans can create additional sandbox workloads and storage use.

## Supporting services

The reference deployment uses these services:

| Service                      | Role                                                                                                     |
| ---------------------------- | -------------------------------------------------------------------------------------------------------- |
| MySQL                        | Application records and database persistence for workflows.                                              |
| Temporal                     | Coordination of background workflows and tasks.                                                          |
| Qdrant                       | Vector indexes used to retrieve code context.                                                            |
| S3-compatible object storage | Source files and stored artifacts. The deployment can use an agreed storage service such as S3 or MinIO. |

The deployment review determines which services are included in the cluster and which can use an existing service. Vidoc confirms the compatible versions and configuration in the supplied runbook. Refer to [Preparing your infrastructure](/deployment/infrastructure).

## Connections to your services

* **Source code platform:** Vidoc reads repository content, receives webhook events, and posts PR results. Available integrations are listed in [Supported platforms](/supported-platforms).
* **Identity provider:** users sign in with your company account through OIDC.
* **LLM service:** Vidoc sends model requests to the configured provider. The reference self-hosted configuration uses AWS Bedrock in your AWS account, including an embedding model for code context.

The deployment review covers the provider account, model access, region, quotas, and permitted connections. Any alternate configuration must be reviewed with Vidoc.

## How data moves during a scan

1. A webhook, a user action, or a CLI request starts work for a repository.
2. Vidoc obtains source content from the source code platform or a CLI upload and prepares code context in its data services.
3. Workers coordinate the scan. Agents inspect source content in workspaces and make requests to the configured LLM service. Model requests can include source code, findings, and prompts.
4. Vidoc stores findings and scan state. Users see results in the web app, and enabled integrations post results to the source code platform.

The configured LLM service is part of the data flow even when Vidoc runs on premises. Review processing locations and provider terms for your deployment. Refer to [Data handling and security review](/deployment-options#data-handling-and-security-review).

For connection planning, refer to [Networking and access](/deployment/networking).