How Self-Hosting VDF AI Works: Portal and Credentials

Self-hosting VDF AI means your platform team runs the product inside infrastructure your organisation controls. The docs describe it as the same product as the managed service, delivered as container images that you run on your own hosts or cluster. What changes is ownership: where the data lives, who operates the stack and when updates arrive.

This article covers what you meet before a single container starts: the portal, the packages it lists and the credentials it issues. Everything here comes from the VDF AI self-hosting documentation.

When self-hosting is the right choice

The docs treat the managed service as the default for most teams, and self-hosting as the answer to a specific constraint. The usual ones are:

• Data that may not leave your network: regulated records, classified work, or customer data under residency clauses.
• A security model that requires the AI stack to sit behind your own firewall.
• An air-gapped or hybrid-cloud topology.
• A requirement to keep inference, audit records and day-to-day operations under your own control.

If none of these applies, the docs suggest starting with the managed service, which gets a team working in minutes, and moving to self-hosting when a real constraint appears.

Who owns what

The two options deploy the same product. The difference is who carries the operational work:

Concern	Managed service	Self-hosted
Location of your data	The VDF AI cloud	Your own environment
Who operates it	VDF AI	Your platform team
Updates	Continuous	Pulled when you choose
Network model	Reachable from the internet	Inside your perimeter

Inside your organisation, the docs split the work three ways. The compliance lead owns the reason for self-hosting: residency, EU AI Act readiness and audit posture. The platform or SRE team owns the method: sizing, orchestration, observability and updates. The security team owns the gates: where images come from, which network paths are allowed and how secrets are handled. Name a person for each role before you register.

Packages: the unit you deploy

VDF AI publishes self-hostable software as packages. A package is a curated set of services and configuration that you deploy together and that behaves as one product. For each package available to you, the catalogue shows:

• a name and a one-line description;
• the current version your account can pull, listed per channel if you can use more than one, such as stable and preview;
• system requirements for compute, memory, storage and network, in plain operator language;
• the services that make up the package;
• an install guide covering bring-up, configuration and first run.

The catalogue currently lists one package, VDF AI Compliance Foundation, an EU AI Act compliance platform. The docs say further packages will follow. When one is published and your account has access, it appears in your catalogue without a new registration.

What the portal does, and what it leaves to you

Self-hosting starts at portal.vdf.ai. The portal has three jobs. It authorises your organisation to use self-hosted packages. It publishes the catalogue of packages you are entitled to. And it issues time-limited credentials for pulling their container images.

What it does not do matters as much. The portal never deploys anything. It has no route back into your systems, it does not watch your running instances and it receives no telemetry from them. Billing runs through your normal commercial agreement rather than the portal.

The docs call this one-way trust. The portal is the authority on what your organisation may pull. Once the images are inside your environment, that relationship ends. The deployment does not report back, needs no ongoing connection to the portal and keeps running if the portal cannot be reached.

From registration to an active account

A portal account moves through a small number of states. Knowing them saves time when something seems stuck:

State	What it means
Pending verification	Signed up, but the email link has not been clicked
Pending approval	Email verified; VDF AI is reviewing the registration
Active	Approved, with access to the packages assigned to you
Trial	Active, with an end date
Suspended	Access paused for billing, terms or an administrative reason
Expired	Trial or subscription ended; deployed instances keep running

Approval is a manual review, which the docs expect to take less than one business day. Register first, and let your platform team prepare the target environment while the review runs.

A trial does not reduce what you can do; it only has an end date. As it approaches, the portal shows the days remaining and sends an email reminder. When a trial or subscription expires, software you have already deployed carries on. What stops is your ability to mint credentials for new pulls.

Pull credentials

Choosing Generate credentials on a package returns three things:

• a login command that authenticates your container runtime with the package registry;
• one pull command for each image in the package;
• the exact time the credentials expire.

The credentials expire automatically, typically within 12 hours. The docs give three reasons for keeping them short-lived:

• A leaked credential is useful for hours, not indefinitely.
• There is no long-lived registry key sitting in a pipeline, waiting to be rotated.
• Every set is recorded with a timestamp and the user who minted it, which gives you a natural audit point.

They are also read-only and limited to the images of your assigned packages. They cannot push, delete or change images, reach any other registry, or be raised to a higher privilege. If a set leaks before it expires, the worst outcome is that someone else pulls images your organisation can already pull.

Mint a new set whenever you need one. The usual reasons are a set that ran out mid-pull, a deployment from a different host, or a new cluster node that has to authenticate to the registry. A rate limit of a couple of dozen sets per user per hour exists to stop runaway automation. Ordinary use comes nowhere near it.

Sharing access with your platform team

The portal supports one registered administrator per organisation. That person manages the account and mints the credentials, then passes the login and pull commands to the engineers running the deployment. Because the commands are short-lived and read-only, sharing them for the length of a deploy window is a normal, safe pattern. The credential history in the portal shows when each set was minted and by whom.

What comes next

With the portal and its credentials understood, the next question is the environment the package will run in. The next lesson plans a deployment layer by layer, from compute to governance, first for a pilot and then for production.