Digitale Soevereiniteit Heroveren op Europese Infrastructuur

Jarenlang hoefden we niet na te denken over het uitrollen van onze moderne webapplicaties. Platforms zoals Netlify, Vercel, AWS en Cloudflare maakten het makkelijk om snel en goedkoop full-stack apps te shippen, met sterke standaardinstellingen en uitstekende performance. Dat gemak vormde onze gewoontes. Het was geen bewuste afweging waarbij iedereen koos voor "snelheid boven controle". De meesten van ons zagen het simpelweg niet als een risico.

Toen veranderde een politiek moment dat voor mij. In 2025 legden de Verenigde Staten sancties op aan het Internationaal Strafhof. Microsoft, gebonden door Amerikaanse wetgeving, gaf hier gehoor aan en sloot de accounts van ICC-onderzoekers af.

Dat maakte iets heel concreet: infrastructuur is niet neutraal. Als je vertrouwt op systemen die uiteindelijk onder een andere politieke en juridische realiteit vallen, accepteer je dat jouw vermogen om te opereren van buitenaf beïnvloed kan worden.

Dat was het startpunt. Maar wat me gaande hield, was dat het veranderde in een technisch probleem dat ik écht wilde begrijpen. Voorbij de politieke zorg werd ik de technische kant ingezogen: hoe werken deze deployment-modellen eigenlijk, en wat gebeurt er als je stopt met standaard kiezen voor de grote Amerikaanse platforms?

Ik wilde uitzoeken wat er nodig zou zijn om een moderne full-stack Astro-applicatie op Europese infrastructuur te draaien, op een manier die vergelijkbaar voelt met wat we gewend zijn van Amerikaanse platforms. Niet vergelijkbaar in de zin van een één-op-één kopie van Cloudflare's edge-architectuur, want dat is onrealistisch.

In plaats daarvan definieerde ik "vergelijkbaar" op basis van drie kernvereisten voor een moderne workflow:

• Automatisering: Ik moet kunnen bouwen en deployen via scripts en CI/CD, niet door in een dashboard te klikken.
• Performance: De setup moet een hybride app ondersteunen; statische assets worden snel geserveerd, terwijl server logica dynamisch draait.
• Vertrouwen: De workflow moet betrouwbaar genoeg zijn om in productie te draaien zonder constante handmatige interventie.

Astro was mijn testcase, simpelweg omdat ik het graag gebruik en ik dit in mijn werk ook gebruik. Astro kan statische output genereren, maar heeft ook server routes en hybride rendering. Dat is waar beslissingen over infrastructuur ertoe gaan doen. Je bent niet langer "gewoon een website" aan het deployen. Je zet statische bestanden én server logica tegelijkertijd online, en je hebt een platform nodig dat beide kanten goed ondersteunt.

De kernvraag was simpel: kan ik een Astro-app deployen op Europese infrastructuur en tegelijkertijd aan die drie criteria voldoen?

Mijn eerste poging was met Bunny. De naam Bunny valt vaak als je zoekt naar Europese alternatieven, en met goede reden. Het is gericht op performance en biedt bouwblokken die klinken alsof ze zouden moeten passen bij moderne web-workloads. Ik begon met Bunny Magic Containers omdat dit de simpelste weg was om snel iets draaiende te krijgen.

Ik wist al dat ik een Node.js-applicatie in een Docker-container kon draaien, dus de runtime zelf was geen onbekende. Het echte doel van deze stap was de automatiserings-eis: kon ik deployment-scripts schrijven die een Astro-app betrouwbaar deployen via CI?

Het lukte me om het werkend te krijgen, maar containers waren hier nooit de beste oplossing. Een hele website in een container stoppen is als een vrachtwagen gebruiken om één broodje te bezorgen. Het werkt, maar het is zwaar en het brengt overhead met zich mee die je op de lange termijn niet wilt. Idealiter worden statische bestanden snel en goedkoop geleverd, terwijl alleen de server logica dynamisch draait. Magic Containers waren een nuttige tussenstap, maar ze bevestigden wat ik al verwachtte: om dichter bij moderne deployment-modellen te komen, had ik iets nodig dat gebaseerd is op functies (function-based).

Bunny Edge Scripting leek meer op wat ik eigenlijk wilde, maar ik had moeite om daar voortgang te boeken. De documentatie was voor mij niet toereikend om snel stappen te zetten, en tijdens het experimenteren liep ik tegen fouten aan die ik niet makkelijk kon herleiden. Op een gegeven moment was het niet meer productief en besloot ik een andere richting te verkennen.

Toen begon ik naar Scaleway te kijken. Scaleway viel op omdat het een bredere set diensten aanbood en meer voelde als een compleet platform. Het zag eruit als de plek waar de stukken die ik nodig had realistisch gezien konden bestaan: serverless functions, object storage en genoeg netwerk- en automatisering opties. Het voelde ook directer en minder 'sales-driven'. De documentatie was duidelijk over hoe dingen werken en hoe er van je verwacht wordt dat je ze automatiseert.

Dat automatisering stuk was erg belangrijk. Dashboards zijn handig, maar schalen niet als workflow. Als je iets wilt dat je daadwerkelijk in echte projecten kunt gebruiken, heb je infrastructuur nodig die via API's kan worden aangestuurd, schoon gescript kan worden en via CI/CD kan worden gedeployed.

Om Astro server routes in een serverless functie te draaien, heb je een handler nodig die binnenkomende requests vertaalt naar de vorm die Astro verwacht tijdens runtime. Als proof of concept gebruikte ik eerst een AI-agent om iets te genereren dat werkte binnen een Scaleway serverless functie. Het draaide wel, maar de implementatie was rommelig; het bevatte patronen die niet intentioneel voelden en logica die niet nodig leek. Het was een perfect voorbeeld van iets belangrijks: AI kan code produceren die werkt, maar die toch fundamenteel verkeerd in elkaar zit qua structuur.

Dus heb ik het ontleed en opnieuw opgebouwd. Ik heb tijd besteed aan het lezen van Astro-docs en Scaleway-docs, en ik heb contact opgenomen met Scaleway support om te valideren hoe bepaalde onderdelen gedaan moesten worden. Daarna heb ik de adapter herbouwd tot iets kleiners en begrijpelijkers.

Op dit moment werkt het kernidee. Ik kan de server logica deployen als een serverless functie, deployments automatiseren via scripts en aparte omgevingen opzetten per feature-branch. Maar als ik terugkijk naar mijn criteria, ligt de volgende stap bij performance. Statische assets zitten voorlopig nog gebundeld in het functiepakket. Dit werkt, maar het bundelen van statische assets maakt je functie opgeblazen, en opgeblazen functies zijn de vijand van snelle koude starts. Als je lichtgewicht functies, snelle opstarttijden en een schoon schaalmodel wilt, horen statische assets ergens anders te wonen.

De logische volgende stap is het goed scheiden van server- en statische omgevingen: functies voor server logica, object storage voor statische assets, en een schone manier om die twee te verbinden.

En daar wordt het weer interessant, want de resterende uitdaging is niet "kan ik iets deployen". Het gaat om de netwerklaag en het integratie verhaal. Cloudflare heeft hier een voordeel; hun mechanisme om assets op te halen is direct in de worker-omgeving verweven. Op Europese platforms kun je in principe hetzelfde idee bouwen, maar de integratie is niet altijd zo voor de hand liggend. Zelfs als je de juiste bouwblokken hebt, moet je ze nog steeds verbinden via routing, caching-gedrag en een schone afhandeling van requests. Het doel is niet om Cloudflare perfect na te maken, maar om te zien hoe ver je kunt komen met een vergelijkbare architectuur en wat de echte gaten zijn.

Dit is ook waar ik denk dat het verhaal "Europa loopt achter" te kort door de bocht is. Ik geloof niet dat Europa de kennis of het talent mist om dit soort systemen te bouwen. De grotere kloof zit in schaal en momentum. Er zijn minder bedrijven die infrastructuurproducten op wereldschaal bouwen, minder standaard "het werkt gewoon"-paden, en minder gedeelde tools rondom moderne deployment-workflows. Niet omdat mensen hier het niet kunnen bouwen, maar omdat het bouwen van platforms op die schaal jaren kost, enorme investeringen vereist en veel iteratie vergt.

Hier pauzeert het verhaal voor nu. Niet omdat het experiment klaar is, maar omdat het resterende werk integratiewerk is: scheiding van statische bestanden, opslag, routing en uitvogelen hoe een schoon model eruit ziet voor echte deployments.

Als er één conclusie is waar ik tot nu toe zeker van ben, is het dit: digitale soevereiniteit is geen schakelaar die je omzet. Het kent gradaties. En we kunnen ons stap voor stap in die richting bewegen.

Maar die beweging gebeurt niet vanzelf. Er is vraag nodig. Het heeft developers nodig die druk uitoefenen, die adapters bouwen, die deployment-strategieën ontwikkelen en delen voor Europese platforms, en idealiter die platforms bij het proces betrekken als ze daarvoor openstaan. Amerikaanse platforms werden niet per ongeluk 'moeiteloos'. Hun ecosystemen werden volwassen omdat mensen de tools bouwden en deployment behandelden als een eersteklas developer experience-probleem.

Als we willen dat Europese infrastructuur een serieuze standaardoptie wordt voor moderne web-apps, moeten we dat ecosysteem zelf gaan bouwen. Zelfs als het in het begin rommelig is. Zelfs als de eerste versies slechts een proof of concept zijn. Dat is hoe je de basis legt voor iets dat uiteindelijk betrouwbaar genoeg wordt voor iedereen om te gebruiken.