[{"data":1,"prerenderedAt":293},["ShallowReactive",2],{"DefaultLayouten":3,"language-blog-slug-reclaiming-digital-sovereignty-on-european-infrastructure-i18n-slugs":134,"language-blog-slug-en-reclaiming-digital-sovereignty-on-european-infrastructure":141},{"app":4,"menu":31,"footer":66},{"githubUrl":5,"youtubeUrl":6,"linkedinUrl":7,"phoneNumber":8,"emailAddress":9,"legal":10,"addresses":20},"https:\u002F\u002Fgithub.com\u002Fvoorhoede\u002F","https:\u002F\u002Fwww.youtube.com\u002Fchannel\u002FUCzHuhQVYFRixtQN2-swcuGg","https:\u002F\u002Fwww.linkedin.com\u002Fcompany\u002Fde-voorhoede","+31 20 2610 954","post@voorhoede.nl",[11,14,17],{"title":12,"value":13},"KvK","56017235",{"title":15,"value":16},"BTW","NL851944620B01",{"title":18,"value":19},"IBAN","NL14TRIO0320142078",[21,26],{"address":22,"city":23,"googleMapsLink":24,"postalCode":25},"Koivistokade 70","Amsterdam","https:\u002F\u002Fwww.google.com\u002Fmaps\u002Fplace\u002FDe+Voorhoede+%7C+Front-end+Development\u002F@52.396847,4.8700823,17z\u002Fdata=!3m1!4b1!4m5!3m4!1s0x47c5e21d502d2d59:0xbf570944a96ebf45!8m2!3d52.347647!4d4.8502154","1013 BB",{"address":27,"city":28,"googleMapsLink":29,"postalCode":30},"Koornmarkt 22","Delft","https:\u002F\u002Fwww.google.nl\u002Fmaps\u002Fplace\u002FKoornmarkt+22,+2611+EG+Delft\u002F@52.0093477,4.3573054,17z\u002F","2611 EG",{"title":32,"callToActions":33,"links":39},"Site Menu",[34],{"id":35,"title":36,"link":37},"163140902","Contact",{"__typename":38},"ContactRecord",[40,46,51,56,61],{"id":41,"title":42,"link":43},"163140904","Impact",{"__typename":44,"slug":45},"PageRecord","impact",{"id":47,"title":48,"link":49},"163140905","Services",{"__typename":50},"ServiceOverviewRecord",{"id":52,"title":53,"link":54},"163140906","Cases",{"__typename":55},"CaseOverviewRecord",{"id":57,"title":58,"link":59},"163140908","About us",{"__typename":44,"slug":60},"about-us",{"id":62,"title":63,"link":64},"d6WdFJq2SOuc3dWtpibbXQ","Work at",{"__typename":44,"slug":65},"work-at",{"links":67,"copyrightTitle":93,"copyrightLabel":94,"copyrightLink":95,"privacyTitle":96,"privacyLabel":97,"privacyLink":98,"certificatesGrid":99},[68,71,74,77,82,85,88],{"id":69,"title":42,"link":70},"144185264",{"__typename":44,"slug":45},{"id":72,"title":48,"link":73},"144185265",{"__typename":50},{"id":75,"title":53,"link":76},"144185266",{"__typename":55},{"id":78,"title":79,"link":80},"144185267","Blog",{"__typename":81},"BlogPostOverviewRecord",{"id":83,"title":58,"link":84},"144185268",{"__typename":44,"slug":60},{"id":86,"title":36,"link":87},"144185269",{"__typename":38},{"id":89,"title":90,"link":91},"144185270","FAQ",{"__typename":44,"slug":92},"faq","Creative Commons licence and disclaimer","CC BY 4.0","https:\u002F\u002Fcreativecommons.org\u002Flicenses\u002Fby\u002F4.0\u002F","De Voorhoede privacy statement (pdf)","Privacy statement","https:\u002F\u002Fwww.datocms-assets.com\u002F6524\u002F1763455455-vh-isms-006-privacy-statement-de-voorhoede-en.pdf",[100,112,123],{"id":101,"image":102,"link":107},"Xq4bBfg_TZ6Fkjax9mkbLQ",{"url":103,"alt":104,"width":105,"height":106},"https:\u002F\u002Fwww.datocms-assets.com\u002F6524\u002F1687353463-b-corp-logo-black-rgb.png","B Corp logo",404,680,{"__typename":108,"id":109,"title":110,"url":111},"ExternalLinkRecord","fGW1ak8XQYaYDLkBSyncog","B Corp","https:\u002F\u002Fwww.bcorporation.net\u002Fen-us\u002Ffind-a-b-corp\u002Fcompany\u002Fde-voorhoede\u002F",{"id":113,"image":114,"link":119},"c5mCXRTiSraRIB25fw1p7Q",{"url":115,"alt":116,"width":117,"height":118},"https:\u002F\u002Fwww.datocms-assets.com\u002F6524\u002F1687353461-dda-boxlogo-black.png","Dutch Digital Agencies logo",627,480,{"__typename":108,"id":120,"title":121,"url":122},"P6Jh7B0cTv2cKyNEeKVWVQ","Dutch Digital Agencies","https:\u002F\u002Fdutchdigitalagencies.com\u002Fleden\u002Fde-voorhoede\u002F",{"id":124,"image":125,"link":129},"MT5SCyNxSTSr_v5eeATMZw",{"url":126,"alt":127,"width":128,"height":128},"https:\u002F\u002Fwww.datocms-assets.com\u002F6524\u002F1775730283-dnv.png","DNV logo",518,{"id":130,"title":131,"link":132},"BRtNB5HnT5i-7HkA8IYzBw","DIV",{"__typename":44,"slug":133},"impact\u002Fdigitale-producten-privacy-by-design",[135,138],{"locale":136,"value":137},"en","reclaiming-digital-sovereignty-on-european-infrastructure",{"locale":139,"value":140},"nl","digitale-soevereiniteit-heroveren-op-europese-infrastructuur",{"page":142},{"slug":137,"i18nSlugs":143,"social":146,"title":148,"subtitle":79,"isArchived":151,"headerIllustration":152,"date":157,"authors":158,"introTitle":167,"items":168,"pivots":206,"relatedBlogPosts":222,"tags":241,"onMountedScript":172,"onUnmountedScript":172},[144,145],{"locale":136,"value":137},{"locale":139,"value":140},{"title":147,"description":148,"image":149},"Independence from American technology","Reclaiming Digital Sovereignty on European Infrastructure",{"url":150},"https:\u002F\u002Fwww.datocms-assets.com\u002F6524\u002F1769684464-2026-01-29_blog-post-luuk-en.jpg",false,{"url":153,"alt":154,"width":155,"height":156},"https:\u002F\u002Fwww.datocms-assets.com\u002F6524\u002F1769688370-2026-01-28-voorhoede-eu-planten.png",null,1190,1278,"2026-01-29T12:02:28.591+01:00",[159],{"name":160,"lastName":161,"slug":162,"image":163},"Luuk","Braukmann","luuk",{"url":164,"alt":154,"width":165,"height":166},"https:\u002F\u002Fwww.datocms-assets.com\u002F6524\u002F1721036156-luuk-edit-edit.jpg",2198,2969,"Digital sovereignty is no longer just a policy topic. It’s starting to show up as a real infrastructure concern in places where most developers never had to think about it before.",[169,174,178,182,186,190,194,198,202],{"__typename":170,"id":171,"title":172,"body":173},"TextSectionRecord","cOYiPm0KRX-XMlTlAXYzlw","","\u003Cp>\u003Cspan style=\"font-weight: 400;\">For years, deploying modern web applications has been almost frictionless. Platforms like Netlify, Vercel, AWS, and Cloudflare made it easy to ship full-stack apps quickly and cheaply, with strong defaults and excellent performance. That convenience shaped our habits. It wasn’t a deliberate tradeoff where everyone consciously chose “speed over control.” Most of us simply didn’t see it as a risk.\u003C\u002Fspan>\u003C\u002Fp>",{"__typename":170,"id":175,"title":176,"body":177},"Hs2FIz8ZQzuXFnLEPNjDsA","When Infrastructure Stops Being Neutral","\u003Cp>\u003Cspan style=\"font-weight: 400;\">Then a political moment changed that for me. In 2025, \u003Cstrong>the United States imposed sanctions on the International Criminal Court\u003C\u002Fstrong>. Microsoft, bound by US law, complied and shut down the accounts of ICC investigators.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">That made something very real: \u003Cstrong>infrastructure is not neutral. \u003C\u002Fstrong>If you rely on systems that ultimately fall under a different political and legal reality, you’re accepting that your ability to operate can be affected from the outside.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">That’s what got me started. But what kept me going was that it turned into a technical problem I genuinely wanted to understand. Beyond the political concern, I got pulled into the engineering side of it: how do these deployment models actually work, and what happens if you stop defaulting to the big US platforms?\u003C\u002Fspan>\u003C\u002Fp>",{"__typename":170,"id":179,"title":180,"body":181},"cVTC7i5OSWeToB0tP5AwfA","Seeking Modern Developer Experience on EU Soil","\u003Cp>\u003Cspan style=\"font-weight: 400;\">I wanted to find out what it would take to deploy a modern full-stack Astro application on European infrastructure, in a way that feels comparable to what we’re used to on American platforms. Not comparable in the sense of matching Cloudflare’s edge architecture one-to-one, because that’s unrealistic.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">Instead, I defined \"comparable\" based on three core requirements needed for a modern workflow:\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cul>\n\u003Cli style=\"font-weight: 400;\" aria-level=\"1\">\u003Cspan style=\"font-weight: 400;\">Automation: I need to be able to build and deploy via scripts and CI\u002FCD, not by clicking in a dashboard.\u003C\u002Fspan>\u003C\u002Fli>\n\u003Cli style=\"font-weight: 400;\" aria-level=\"1\">\u003Cspan style=\"font-weight: 400;\">Performance: The setup must support a hybrid app, meaning it serves static assets fast while running server logic dynamically.\u003C\u002Fspan>\u003C\u002Fli>\n\u003Cli style=\"font-weight: 400;\" aria-level=\"1\">\u003Cspan style=\"font-weight: 400;\">Trust: The workflow must be reliable enough to run in production without constant manual intervention.\u003C\u002Fspan>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">Astro was my test case simply because I like using it and it matches the kind of applications I want to build. Astro can produce static output, but it also has server routes and hybrid rendering. That’s where infrastructure decisions start to matter. You’re no longer deploying “just a static website.” You’re deploying static files and server logic together, and you need a platform that supports both sides well.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">The question I tried to answer was straightforward: can I deploy an Astro app on European infrastructure while hitting those three criteria?\u003C\u002Fspan>\u003C\u002Fp>",{"__typename":170,"id":183,"title":184,"body":185},"dqEoRiP-TmOkd40AmoG03g","Why Containers Are the Wrong Tool for the Job","\u003Cp>\u003Cspan style=\"font-weight: 400;\">My first attempt was Bunny. Bunny often comes up when you search for European alternatives, and for good reason. It’s performance-focused, and it offers building blocks that sound like they should fit modern web workloads. I started with Bunny Magic Containers because it was the simplest path to get something running quickly.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">I already knew I could run a Node.js application inside a Docker container, so the runtime itself wasn’t the unknown. The real goal of this step was the automation requirement: could I write deployment scripts that deploy an Astro app reliably, and support feature-branch deployments and cleanup through CI?\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">I managed to get it working, but it wasn’t the end goal. Containers were never the best solution here. Putting an entire website inside a container is like using a truck to deliver a single sandwich. It works, but it’s heavy, and it comes with overhead you don’t want long term. Ideally, static files should be delivered fast and cheaply, while only the server logic runs dynamically. So Magic Containers were a useful stepping stone, but they confirmed what I already expected: to get closer to modern deployment models, I would need something function-based.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">Bunny Edge Scripting looked closer to what I actually wanted, but I struggled to make progress there. Not because I proved it was impossible, but because I couldn’t get enough clarity to confidently build a deployment flow around it. The documentation wasn’t enough for me to move quickly, and while experimenting I kept running into errors I couldn’t easily reason about. At some point it stopped being productive, and I decided to explore a different direction.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003C!-- notionvc: 57f1f17a-4d92-427a-8ae8-2ac74719f19c -->\u003C\u002Fp>",{"__typename":170,"id":187,"title":188,"body":189},"J80fT15SS5u2F0pTB1fNIA","Shifting to a Serverless Architecture on Scaleway","\u003Cp>\u003Cspan style=\"font-weight: 400;\">That’s when I started looking into Scaleway. Scaleway stood out because it offered a broader set of services and felt more like a complete platform. It looked like the kind of place where the pieces I needed could realistically exist: serverless functions, object storage, and enough networking and automation options to build something closer to the setup I had in mind. It also felt more direct and less sales-driven. The docs were clear about how things work and how you’re expected to automate them.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">That automation part mattered a lot. Dashboards are useful, but they don’t scale as a workflow. If you want something you can actually use in real projects, you need infrastructure that can be driven through APIs, scripted cleanly, and deployed through CI\u002FCD.\u003C\u002Fspan>\u003C\u002Fp>",{"__typename":170,"id":191,"title":192,"body":193},"YOpVfzMfSZ-WZNTy-hDZpA","Reverse Engineering a Custom Adapter","\u003Cp>\u003Cspan style=\"font-weight: 400;\">To run Astro server routes in a serverless function, you need a handler that translates incoming requests into whatever shape Astro expects at runtime. For proof of concept, I first used an AI agent to generate something that worked inside a Scaleway serverless function. It did run, but the implementation was messy. It contained patterns that didn’t feel intentional, and logic that didn’t seem necessary. It was a perfect example of something important: AI can produce code that works, but still be fundamentally wrong in how it’s structured.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">So I reverse engineered it. I spent time reading Astro docs and Scaleway docs, and I discussed ideas with Scaleway support to validate how certain parts should be done. Then I rebuilt the adapter into something smaller and easier to understand.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">At this point, the core idea is working. I can deploy the server logic as a serverless function, automate deployments through scripts, and spin up separate environments per feature branch. However, looking back at my criteria, performance is where the next step lies. Static assets are still bundled inside the function package for now. This works, but bundling static assets makes your function bloated, and bloated functions are the enemy of reducing cold starts. If you want lightweight functions, quick startup times, and a clean scaling model, static assets should live somewhere else.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003C!-- notionvc: 9a783e11-c034-4fe5-bc06-6644dc31472b -->\u003C\u002Fp>",{"__typename":170,"id":195,"title":196,"body":197},"ZRPCyclATGS8i7wyCh2uIg","The Challenge of Bridging the Integration Gap","\u003Cp>\u003Cspan style=\"font-weight: 400;\">The obvious next step is separating server and static environments properly: functions for server logic, object storage for static assets, and a clean way to connect the two.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">And that’s where this gets interesting again, because the remaining challenge isn’t “can I deploy something.” It’s the network layer and the integration story. Cloudflare has an advantage here. When I look at their approach, I see an assets fetch mechanism wired into the worker environment. My assumption is that this is heavily optimized behind the scenes. I don’t know all the details, but it clearly helps make the connection between “server logic” and “static assets” feel native and fast. On European platforms, you can build the same idea in principle, but the integration isn’t always as obvious. Even when you have the right building blocks, you still need to connect them through routing, caching behavior, and clean request handling. The goal isn’t to perfectly replicate Cloudflare. The goal is to see how far you can get with a similar architecture, and what the real gaps are.\u003C\u002Fspan>\u003C\u002Fp>",{"__typename":170,"id":199,"title":200,"body":201},"ZEhvbYkkRjC2u_8bwDBSlw","Digital Sovereignty is a Gradient","\u003Cp>\u003Cspan style=\"font-weight: 400;\">This is also where I think the “Europe is behind” narrative is too simplistic. I don’t believe Europe lacks the knowledge or talent to build systems like this. The bigger gap is scale and momentum. There are fewer companies building global-scale infrastructure products, fewer default “it just works” paths, and less shared tooling around modern deployment workflows. Not because people here can’t build it, but because building platforms at that scale takes years, massive investment, and a lot of iteration.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">This is where the story pauses for now. Not because the experiment is finished, but because the remaining work is integration work: static separation, storage, routing, and figuring out what a clean model looks like for real-world deployments.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">If there’s one conclusion I’m confident about so far, it’s this: digital sovereignty is not a switch you flip. It’s a gradient. And we can move toward it.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan style=\"font-weight: 400;\">But that movement won’t happen automatically. It needs demand. It needs developers to create pressure, to build adapters, to develop and share deployment strategies for European platforms, and ideally to involve those platforms in the process if they’re open to it. American platforms didn’t become effortless by accident. Their ecosystems matured because people built the tooling, refined the workflows, and treated deployment as a first-class developer experience problem.\u003C\u002Fspan>\u003C\u002Fp>",{"__typename":170,"id":203,"title":204,"body":205},"VLcpURp_QDSkHHNLaE_U2Q","Wrapping up","\u003Cp>\u003Cspan style=\"font-weight: 400;\">If we want European infrastructure to become a serious default option for modern web apps, \u003Cstrong>we\u003C\u002Fstrong> \u003Cstrong>need to start building that ecosystem ourselves\u003C\u002Fstrong>. Even if it’s messy at first. Even if the first versions are only proof of concept. That’s how you create the foundation for something that eventually becomes reliable enough for everyone to use.\u003C\u002Fspan>\u003C\u002Fp>",[207],{"title":208,"body":172,"links":209,"mailchimpValue":172,"mailchimpName":172,"mailchimpId":172,"formType":172,"contactPerson":215},"Got a project we can work on?",[210],{"__typename":211,"id":212,"title":213,"link":214},"InternalLinkRecord","163140952","Contact us",{"__typename":38},{"name":216,"lastName":172,"jobTitle":217,"image":218},"Jasper","CTO, Co-founder",{"url":219,"alt":154,"width":220,"height":221},"https:\u002F\u002Fwww.datocms-assets.com\u002F6524\u002F1683535518-jasper.jpg",1892,2523,[223,230],{"slug":224,"title":225,"date":226,"authors":227},"how-close-to-the-user-should-your-code-be","How close to the user should your code be?","2025-10-30T10:07:10.411+01:00",[228],{"name":216,"image":229},{"url":219,"alt":154,"width":220,"height":221},{"slug":231,"title":232,"date":233,"authors":234},"write-components-once-run-everywhere-with-mitosis-a-beautiful-dream-or-reality","“Write components once, run everywhere” with Mitosis; a beautiful dream or reality?","2024-09-16T13:04:31.307+02:00",[235],{"name":236,"image":237},"Wessel",{"url":238,"alt":236,"width":239,"height":240},"https:\u002F\u002Fwww.datocms-assets.com\u002F6524\u002F1721035942-wessel.jpg",2135,2868,[242,265],{"id":243,"title":244,"slug":245,"blogPosts":246},"NJN9K2rdSY2pn9MvchHLtw","Strategy","strategy",[247,251,258],{"slug":224,"title":225,"date":226,"authors":248},[249],{"name":216,"image":250},{"url":219,"alt":154,"width":220,"height":221},{"slug":252,"title":253,"date":254,"authors":255},"future-front-end-replaceable-inadequate-innovative","The future of front-end: replaceable, inadequate or innovative?","2022-07-18T02:00:00.000+02:00",[256],{"name":216,"image":257},{"url":219,"alt":154,"width":220,"height":221},{"slug":259,"title":260,"date":261,"authors":262},"full-stack-front-end","Full-stack Front-end","2022-07-19T02:00:00.000+02:00",[263],{"name":216,"image":264},{"url":219,"alt":154,"width":220,"height":221},{"id":266,"title":267,"slug":268,"blogPosts":269},"b-HOCOQTRJKMsff0UxhDcg","Web performance ","web-performance",[270,274,285],{"slug":224,"title":225,"date":226,"authors":271},[272],{"name":216,"image":273},{"url":219,"alt":154,"width":220,"height":221},{"slug":275,"title":276,"date":277,"authors":278},"lessons-learned-debugging-inp"," Lessons learned debugging Interaction to Next Paint (INP)","2024-08-16T09:46:11.712+02:00",[279],{"name":280,"image":281},"Declan",{"url":282,"alt":154,"width":283,"height":284},"https:\u002F\u002Fwww.datocms-assets.com\u002F6524\u002F1683534636-placeholder.jpg",1235,1646,{"slug":286,"title":287,"date":288,"authors":289},"front-end-at-the-edge","Front-end at the Edge","2022-10-04T02:00:00.000+02:00",[290],{"name":291,"image":292},"Vera",{"url":282,"alt":154,"width":283,"height":284},1776256134371]