Network, TLS, SSO and Secrets for Self-Hosted AI

A self-hosted package should slot into the edge your organisation already runs. The self-hosting docs are consistent on this point. TLS ends at your reverse proxy, single sign-on goes through your identity provider, secrets stay in your tooling and, for isolated networks, images come from your own registry. Nothing in the package asks you to build a second edge beside the first.

This lesson takes those decisions in the order a security review tends to raise them. First comes what leaves the network, then what moves inside it, how users get in, where secrets live and how an isolated site is supplied.

Outbound: what the deployment has to reach

The list is short:

• The package registry, over HTTPS. The login and pull commands from the portal connect to the registry endpoint named in the credentials block. You need this whenever you pull images: for the first deployment and for each update.
• Update channels, optionally. A package can check over HTTPS whether newer versions exist. Most operators prefer to leave this off and pull updates on a schedule they set. Either model works.
• Integrations you connect. If you later connect apps to the deployed package, it needs a route to each of them. Treat every one as its own firewall decision.

No inbound ports are required on your side. The portal never connects to your environment, and a running deployment does not need the portal to stay up. Open the outbound rule for image pulls while your portal account is waiting for approval, so it is in place when access arrives.

Inside the package: keep traffic narrow

The services in a package talk to each other over a short internal hop: the default bridge network under Docker Compose, or the cluster network under Kubernetes. Treat that traffic as you would any internal service traffic. The docs recommend restrictive network policies: allow what the package needs and deny everything else. The package’s install guide says what, if anything, has to be tuned for traffic between its services in your environment.

Ingress and TLS at your edge

Users reach the package through its frontend service. Put your own load balancer or reverse proxy in front of it and terminate TLS there. Use the certificate authority your organisation already trusts, whether that is a corporate, public or private internal CA. The package does not require a particular certificate vendor.

Settle three points before the first bring-up:

• the hostname users will open;
• the proxy or load balancer that serves it;
• where its certificate comes from, and who renews it.

Together these form the TLS and ingress line of the pre-deploy checklist. Agreeing them early avoids a healthy deployment that nobody can reach.

Single sign-on at the reverse proxy

Every package includes its own user account management, so a pilot can run without any identity integration. For production, most teams put an SSO-aware reverse proxy in front of the package and authenticate with SAML or OIDC. The install guide for each package describes the recommended pattern.

Placing SSO at the edge is a deliberate design choice. The relationship with your identity provider stays between the provider and your own infrastructure rather than moving into the package, so you keep control of it.

Plan the account side as well. After bring-up, the package’s first-run setup creates the initial administrator, and its user management is where the rest of the team is added. Agree who holds that first administrator account before deployment day.

Secrets: environment file or secrets manager

A package needs only a handful of secrets: the database password, signing keys and tokens for any connected apps. The docs describe two patterns:

• An environment file. The simplest model, and suitable for a single host behind strict access controls. The recommended Compose setup reads its few values from one.
• Your secrets manager. For production, keep the values in the store you already operate, such as Vault, or Kubernetes Secrets backed by an external secrets store. Each package’s install guide maps the values across.

There are no VDF AI-specific secret formats, so the tooling your team uses for other services applies here too.

Registry credentials are a different case. They are short-lived by design, so there is nothing to keep long term. Mint a set when you need to pull and let it expire, rather than copying it into a pipeline.

The air-gapped route

A network with no outbound internet can still run a package. The images travel in by way of a machine that can reach the registry:

1. Mint credentials in the portal from a machine outside the isolated network.
2. Pull the images onto that machine, which acts as your staging host.
3. Push them into your internal registry, whether that is Harbor, Artifactory or another registry you run.
4. Inside the air-gapped environment, point the deployment at the internal registry.

The docs describe this as a standard pattern, and each package’s install guide covers it. VDF AI will also walk through a specific setup on request.

Two practical points follow from how credentials work. Pull promptly once you have minted a set, because it expires. And plan for newer versions to arrive the same way, through the staging host and your internal registry, since the air-gapped side never reaches the package registry directly. On the pre-deploy checklist, the outbound registry line becomes a check that the internal mirror is reachable.

The docs cover moving package images. An isolated programme usually has more to bring across, and a formal import review for each transfer. The patterns for restricted networks and the post on offline patching deal with those wider questions.

A review sheet for the edge

Bring the decisions together before the security review:

Decision	Pilot	Production
Outbound	HTTPS to the package registry	The same, or the internal mirror only for an air-gapped site
Internal traffic	Compose bridge network	Restrictive cluster network policies
Ingress and TLS	Your reverse proxy and certificate authority	Your load balancer or proxy and certificate authority
Identity	The package’s own user accounts	SSO at the reverse proxy, over SAML or OIDC
Secrets	Environment file with strict access	Your secrets manager

Fill in the hostname, the certificate source and the identity protocol, and the sheet is ready to review. The last lesson in this path carries it into the pre-deploy checklist and the first bring-up.