Skip to main content
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. 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. 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.

​
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. 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 for the joint validation stage.