> ## 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.

# Networking and access

> Plan the addresses and connections that users, integrations, and Vidoc workloads need.

Vidoc needs connections between users, application workloads, supporting services, and the integrations selected for your deployment. Review these paths with your network team before installation. The supplied runbook specifies the endpoints and ports for your environment.

## Private network access

The Vidoc web app and API can use internal addresses and private ingress. They do not need to be exposed to the public internet when users, CI runners, and the source code platform can reach them over your internal network.

With self-managed GitLab or Bitbucket Data Center inside that network, repository access, webhook delivery, and PR comments can all use internal connections. The GitHub integration currently connects to GitHub.com; refer to [Supported platforms](/supported-platforms#availability-by-deployment).

For a deployment with no public-internet access at runtime, plan private access to every required dependency. This includes the identity provider, LLM and embedding services, storage, workflow services, and image registry. Agree on the treatment of telemetry and update checks for the supplied release, then verify the complete deployment with your network restrictions in place.

Private access to a cloud model service keeps the connection off the public internet, but the provider still processes the model request. Keeping all processing within your own infrastructure requires a compatible model service within that boundary as well. Vidoc reviews the full service configuration with your team before confirming that deployment model.

## Web app and API addresses

A self-hosted installation uses your own addresses for the web app and API, for example `https://app.example.com` and `https://api.example.com`.

| Address | Who uses it                                                                                        |
| ------- | -------------------------------------------------------------------------------------------------- |
| Web app | Users signing in, reviewing findings, and managing Vidoc. Links in scan results open this address. |
| API     | CLI clients, automation, and source code platforms delivering webhooks.                            |

Agree on DNS, ingress, HTTPS, and the networks that can reach each address. Use the API address of your installation for CLI and REST requests. Refer to [API addresses](/api/authentication#base-url).

## Connection plan

This table describes the main connections in the reference deployment. It is an input to the environment review; the runbook provides the complete connection list for the selected services.

| Source                         | Destination                           | Purpose                                                                                 |
| ------------------------------ | ------------------------------------- | --------------------------------------------------------------------------------------- |
| Users' browsers                | Vidoc web app                         | Sign-in and use of the application.                                                     |
| CLI clients and CI runners     | Vidoc API                             | Upload source content, start scans, and read results.                                   |
| Source code platform           | Vidoc API                             | Deliver PR and repository webhook events.                                               |
| Vidoc application workloads    | Source code platform                  | Read repositories and integration data, manage supported webhooks, and post PR results. |
| Browsers and Vidoc web service | Identity provider                     | OIDC sign-in and token exchange.                                                        |
| Vidoc application workloads    | Configured LLM and embedding services | Model requests and code-context embeddings.                                             |
| Application and scan workloads | Internal workflow and data services   | Coordinate scans and access databases, indexes, and object storage.                     |
| Sandbox control services       | Kubernetes API                        | Manage sandbox workloads.                                                               |
| Cluster nodes                  | Your selected image registry          | Pull application, job, sandbox, and supporting-service images.                          |
| Your image-copying system      | Supplied image registries             | Retrieve release images for your own registry, when you use mirroring.                  |

GitHub.com needs a webhook path from outside your network. An internal self-managed GitLab or Bitbucket Data Center instance can deliver webhooks directly to the private Vidoc API. CI runners need access from the network where they run.

## Registry mirroring and runtime connections

Vidoc supplies access to its private Docker Hub images. You can copy them into your own registry before deployment. Include the supporting and sandbox images identified in the release package.

Image retrieval and runtime access are separate parts of the connection plan. You can transfer release images through your approved process and make them available in an internal registry before deployment. Runtime connections to source control, the identity provider, and the LLM service then follow the private or external paths agreed for your environment.

## Service exposure and access ownership

Keep database, workflow, vector-index, and sandbox control services on the internal service network. Plan user and integration access through the web app and API entry points.

Assign owners for DNS, ingress, registry credentials, source control credentials, and identity-provider configuration. Confirm how those owners will coordinate changes with the Vidoc operators.

The installation and connectivity checks are provided in the runbook. Refer to [Deployment process](/deployment/process) for the joint validation stage.