How to Plan a Self-Hosted AI Deployment in Your Data Centre

Running VDF AI in your own data centre is an infrastructure project before it is a software install. No vendor hides the hardware from you: your teams own compute, storage, networking, identity and the governance around them. That ownership is the reason to self-host, because it keeps data and records inside your boundary. It also means each layer needs a decision before the first image is pulled.

This lesson works through the five layers with the self-hosting documentation. Its figures are the foundation every package builds on; each package’s own system requirements in the portal catalogue take precedence.

Name an owner for each layer

Decide who owns each layer before you size anything. The docs give compliance the reason for self-hosting, the platform team the build and the running of it, and security the gates on images, network paths and secrets. If other teams run your network or identity provider, add them. A plan with a named owner per layer is far easier to review.

Compute: size a pilot first, then production

A package is delivered as a set of containers, and its size depends on the package and the load. The docs give two starting profiles:

Resource	Single-host pilot	Production, small to mid-sized team
vCPU	4–8	16–32, spread across nodes
Memory	16–32 GB	64–128 GB
Storage	100 GB SSD	500 GB SSD with a snapshot policy
Network	100 Mbps egress for the first image pull	Predictable 1 Gbps, low latency between nodes

The pilot profile covers a first deployment and lets a small team try the product. For production, a package can be spread across several nodes, and the database should sit on its own instance or a managed service. Larger deployments, with more users, bigger source collections or heavier inference, are sized from real usage. The docs suggest involving the VDF AI team when you scope one.

For hosts, Linux is the default production target. The tested releases include Ubuntu 20.04 or later, Debian 11 or later, and RHEL, Rocky and Alma Linux 8 or later. The images are multi-architecture, so ARM64 hosts are supported too. Docker Desktop on macOS, or on Windows with WSL 2, is fine for trying the product but not recommended for production.

Both profiles are expressed in vCPU, memory and storage; the self-hosting docs publish no GPU figures. If you also plan to run models on your own hardware, size that capacity separately, from the models each task needs and the load you expect. A workload-first GPU estimate is a sound place to start.

Runtime and orchestration

Any current container runtime works: Docker 24 or newer (24.x and 25.x are the most tested), Podman 4 or newer, or containerd. The portal’s login and pull commands are standard, so any OCI-compatible runtime can use them. For orchestration:

• Docker Compose is the quickest route to a first deployment. It suits proofs of value, and single-host production if run with care.
• Kubernetes is the recommended production target. Install guides include manifests or a Helm chart for any conformant cluster.
• Other orchestrators that run OCI containers also work, with a thin adaptation you write yourself.

Storage and the database

Most packages need PostgreSQL 16 or later. For a pilot, the package’s Compose file includes a PostgreSQL container, so there is nothing extra to provision. For production, point the package at a managed PostgreSQL service or your own clustered PostgreSQL; the install guide covers handing over the connection string.

Storage has three parts:

• Container volumes hold package state, uploaded content and cached artefacts. Plan 100 GB or more for production, or whatever the package’s requirements state.
• Database storage depends on usage, and ordinary PostgreSQL sizing applies.
• Backups are snapshots of the database and of any persistent volumes. The cadence is yours to set, but the docs treat daily as a sensible floor for production, with a restore drill as part of normal database operations.

Use SSD-backed storage. Spinning disks will do for a trial, but the docs warn that production on slow storage feels sluggish even at modest load.

Networking

A package needs three network paths:

• Outbound. Image pulls need HTTPS to the package registry. No inbound ports have to be opened on your side. An optional HTTPS connection to update channels lets a package learn about newer versions; most operators prefer to pull updates on a schedule they set.
• Internal. Services in a package talk to each other over a short hop: the default bridge network under Compose, the cluster network under Kubernetes. Keep network policies restrictive, allowing only what the package needs.
• Ingress. Users reach the package through its frontend service, which you normally place behind your own load balancer or reverse proxy, with your existing TLS termination.

If the data centre has no outbound internet access at all, images arrive through a connected staging host and your internal registry. The next lesson covers that route, and TLS, in more detail. For the wider picture of isolated networks, see the guide to air-gapped deployments.

Identity and secrets

Every package includes its own user account management. Most production deployments add single sign-on at the reverse proxy, over SAML or OIDC. That keeps the relationship with your identity provider at your own edge.

A package needs only a few secrets, such as the database password, signing keys and tokens for connected apps. An environment file is enough for a single host behind strict access controls; production belongs in your secrets manager. Standard tooling applies, as there are no VDF AI-specific secret formats.

Governance: the controls you run

In a self-hosted deployment, a large part of governance is how you operate it, and that part is yours from day one:

• Where images come from. Images are pulled from the package registry with portal-issued credentials, which are read-only and recorded against the person who minted them. An air-gapped site adds your internal registry as a second, controlled hop.
• What can talk to what. Restrictive policies between services, and one known outbound path to the registry.
• Evidence. Services write JSON logs to standard output and standard error, each exposes an HTTP health endpoint, and metrics come in a Prometheus-compatible format. Point your existing tooling at them before the first users arrive.
• Change. Updates arrive when you pull them, so new versions pass through your own change process rather than a vendor’s release calendar.

The docs state that deployed packages send no telemetry back to VDF AI, so logs and records stay in your environment under your retention rules. For which of them count as sensitive, see protecting the AI data plane.

The other part of governance is the product itself. The docs describe self-hosted VDF AI as the same product the managed service runs. The package in the catalogue today, VDF AI Compliance Foundation, is itself an EU AI Act compliance platform.

From pilot to production

The docs are plain about sequencing. Almost every successful self-hosted rollout starts as a single-host pilot and grows from there, and re-sizing once real usage is visible carries no penalty. A plan that follows that advice looks like this:

Layer	Pilot	Production
Compute	One host at the baseline profile	Several nodes at the production profile
Orchestration	Docker Compose	Kubernetes, once the pilot is validated
Database	Bundled PostgreSQL container	Managed or clustered PostgreSQL on its own instance
Storage	100 GB SSD	500 GB SSD with snapshots, daily at minimum
Identity	The package’s own user accounts	SSO at the reverse proxy
Secrets	Environment file behind strict access	Your secrets manager
Evidence	Logs checked during validation	Logs, health checks and metrics in your observability stack

Treat the production column as the target and the pilot as the way to gather the usage evidence that justifies it. Starting narrow also brings sizing and operational surprises to light while little depends on the deployment. The next lesson looks closely at the edge of the deployment: network, TLS, single sign-on, secrets and the air-gapped route.