Self-Hosted AI: On-Premises vs. VPC Deployment

“Kunnen we het self-hosten?” is de eerste vraag die de meeste gereguleerde teams stellen over een AI-platform, en het eerlijke antwoord is “ja, maar bepaal eerst welk type.” Self-hosting is geen enkele knop die je omzet. Het is een spectrum, en de twee keuzes die er het meest toe doen, zijn of het platform draait in jouw cloudaccount (VPC) of in je eigen datacenter (on-premises) — met een volledig air-gapped installatie aan het strikte uiteinde van de on-prem optie.

Ze klinken vergelijkbaar omdat beide je workloads in jouw eigen omgeving houden. Ze verschillen in wat je zelf beheert, waar je GPU's vandaan komen, hoeveel netwerkisolatie je krijgt en hoeveel van het platform je zelf draait. Het kiezen van de verkeerde optie betekent ofwel het opnemen van datacenterbeheer dat je niet nodig had, ofwel er laat achterkomen dat een afhankelijkheid van de publieke cloud een complianceprobleem vormt.

Self-hosted is een spectrum, geen schakelaar

Zie deployment als een lijn, waarbij elke stap meer van het platform naar jouw controle verplaatst en meer vraagt van je team.

Aan het ene uiteinde wordt alles voor je beheerd (SaaS). Vervolgens verhuist het data plane naar jouw cloudaccount (VPC/BYOC). Daarna verhuist het gehele platform naar jouw datacenter (on-prem). Aan het uiterste einde draait het helemaal zonder uitgaande internetverbinding (air-gapped). “On-premises vs. VPC” vormt het midden van deze lijn — het gedeelte waar de meeste gereguleerde ondernemingen daadwerkelijk tussen kiezen.

Weet je niet zeker welke deployment past bij jouw compliance-regels?

Boek een demo

De scheiding die beide mogelijk maakt

De reden dat één platform in jouw cloud of in jouw datacenter kan draaien, is dat het twee planes scheidt. Het control plane is waar je deployments beheert en monitort — dit kan door TrueFoundry gehoste SaaS zijn of self-hosted in jouw VPC. Het compute plane is waar je workloads daadwerkelijk draaien: een of meer Kubernetes-clusters in jouw omgeving.

Het cruciale architectonische detail: het control plane grijpt nooit rechtstreeks in op je clusters. Een tfy-agent draait binnen elk cluster, verbindt uitgaand met het control plane via een beveiligde WebSocket, ontvangt deployment-instructies en streamt de workloadstatus terug. Je code, modellen en data verhaten nooit je infrastructuur. Dat specifieke ontwerp zorgt ervoor dat het compute plane zich in een cloud-VPC of een on-prem rack kan bevinden zonder dat de werking van het platform verandert.

VPC deployment (BYOC)

Bij een VPC deployment — bring your own cloud — is het compute plane een beheerd Kubernetes-cluster in jouw cloudaccount: AWS EKS, Google GKE of Azure AKS. Je provisiont het met OpenTofu/Terraform, of koppelt een bestaand cluster dat je al gebruikt. GPU's komen van je cloudprovider, schalen is elastisch, en het beheerde control plane (SaaS of self-hosted) orchestreert het via de agent.

Dit is de ideale optie voor een team dat al actief is in de cloud. Data en workloads blijven binnen jouw account en je VPC-grens, je krijgt cloud-native automatische schaalbaarheid en GPU-beschikbaarheid, en je hoeft geen bare-metal infrastructuur te beheren. Je blijft wel verantwoordelijk voor cluster-hygiëne — upgrades, quota, node pools — maar niet voor een fysiek datacenter.

On-premises deployment

Bij een on-premises deployment is het compute plane jouw eigen cluster — elk standaard Kubernetes- of OpenShift-cluster, inclusief on-prem GPU-clusters en neoclouds. Dit is de optie wanneer een harde regel voorschrijft dat data en inference een publieke cloud absoluut niet mogen raken: gereguleerde data, soevereiniteitseisen of een bestaande GPU-investering die je wilt benutten.

On-prem is ook het pad naar air-gapped, waarbij de omgeving geen uitgaande internetverbinding heeft en elke afhankelijkheid intern gespiegeld is. Je krijgt de strikst mogelijke isolatie, ten koste van het zelf beheren van de volledige stack — het cluster, de GPU's, de opslag en het upgradeproces. De GPU-capaciteit is beperkt tot wat je in de racks hebt hangen, niet tot waar de cloud naar kan uitbreiden, waardoor capaciteitsplanning jouw taak wordt in plaats van die van je provider.

Naast elkaar vergeleken

De beslissing komt meestal neer op twee vragen: mag je data überhaupt in een publieke cloudaccount staan, en wil je hardware beheren? Als de data in je cloud kan staan en je liever geen datacenter beheert, is VPC de winnaar. Als een regel de publieke cloud verbiedt, of als je een air gap nodig hebt, of als je de GPU's al bezit, is on-prem het antwoord.

Wat verlaat daadwerkelijk je omgeving?

De bezorgdheid achter deze beslissing gaat altijd over data, dus concreet: bij zowel VPC als on-prem blijven je code, modellen en verzoekdata in jouw infrastructuur, versleuteld in rust (at rest) en in transit. Het control plane haalt nooit gegevens op uit je clusters — het ontvangt alleen de workloadstatus die de tfy-agent uitstreamt. Als je ook het control plane zelf host, is de enige uitgaande data wat een licentieserver nodig heeft (e-mailadressen van platformgebruikers en aantallen verzoeken, voor facturering). In een air-gapped installatie wordt zelfs dat via een intern proces afgehandeld. Bij elke optie is het datapad hetzelfde; wat verandert is hoeveel van het platform je zelf beheert.

Welke moet je kiezen?

Vertrek vanuit de randvoorwaarde, niet vanuit de voorkeur. Als je data in je cloudaccount mag staan, is VPC de lichtste self-hosted optie en de optie die de meeste teams zouden moeten kiezen — je krijgt isolatie en dataeigenaarschap zonder een datacenter op te tuigen. Stap over op on-premises wanneer een concrete regel dat vereist: data die een publieke cloud niet mag raken, een air-gap-mandaat, wetgeving rond datasoevereiniteit, of GPU's die je al bezit en moet gebruiken. Kies pas voor air-gapped wanneer “geen uitgaand internet” een daadwerkelijke vereiste is, omdat dit het meeste beheer vraagt. De fout is om standaard voor on-prem te kiezen “om veilig te zijn” en daarmee maanden aan infrastructuurwerk op te halen dat een VPC deployment zou hebben voorkomen.

Draai hetzelfde platform van SaaS tot air-gapped, en schaal mee als je regels veranderen.

Boek een demo

Waar teams de fout in gaan

Ze halen “self-hosted” en “on-prem” door elkaar. VPC is ook self-hosted — jouw cloud, jouw data — met aanzienlijk minder operationele druk. Veel teams die zeggen “we hebben on-prem nodig”, hebben eigenlijk een VPC deployment nodig.

Ze budgetteren de on-prem GPU-operaties te laag. In de cloud schaal je elastisch mee; on-prem moet je capaciteit plannen, inbouwen en onderhouden. Dat is een continue, serieuze taak.

Ze vergeten dat het control plane een afzonderlijke keuze is. Je kunt het compute plane on-prem draaien terwijl het control plane op SaaS blijft, of beide self-hosten. Dit zijn onafhankelijke beslissingen.

Ze kiezen air-gapped zonder dat het nodig is. Air-gap betekent dat je elke afhankelijkheid moet spiegelen en het gemak van beheerde diensten verliest. Tenzij een regel eist dat er geen uitgaand internet is, is een niet-air-gapped on-prem of VPC-installatie veel goedkoper in beheer.

Gerelateerde artikelen

• AI gateway on-premise
• LLM gateway on-premise infrastructure
• AI gateway data residency comparison
• Air-gapped AI for regulated industries
• On-premise AI platform

Conclusie

“Self-hosted” is een beslissing met twee reële opties, niet één. VPC houdt je workloads in je cloudaccount met beheerde Kubernetes en cloud-GPU's — het lichtere pad, en het juiste pad voor de meeste teams die data kunnen bewaren in een cloud die ze zelf beheren. On-premises plaatst alles in jouw datacenter, tot een volledig air-gapped installatie aan toe — het juiste pad wanneer een regel de publieke cloud verbiedt of wanneer je de hardware al bezit.

De scheiding tussen control plane en compute plane betekent dat je governance niet hoeft in te ruilen voor isolatie: je data blijft in beide gevallen binnen jouw omgeving, en je kunt meebewegen over het spectrum als je vereisten veranderen zonder van product te hoeven wisselen.

Vind de self-hosted deployment die past bij jouw regels

Boek een demo