# Cloudflare OS review: gadgets en gatekeepers | Apps

[Naar de inhoud](#lm-inhoud)Netwerk/NL[EN](/en/)[Hubhub.llmnet.nlModellen vergelijken op taak, taal, kosten en licentie.](https://hub.llmnet.nl/)[Communitycommunity.llmnet.nlPrompttechnieken, patronen en systeemprompts.](https://community.llmnet.nl/)[APIapi.llmnet.nlLLM's robuust in software: rate limits, routing, structured output.](https://api.llmnet.nl/)[Consultancyconsultancy.llmnet.nlAI invoeren in een organisatie, van pilot tot productie.](https://consultancy.llmnet.nl/)[Nieuwsnieuws.llmnet.nlOntwikkelingen in AI, geduid voor Nederland.](https://nieuws.llmnet.nl/)[Benchmarkbenchmark.llmnet.nlZelf meten wat AI-kwaliteit is, voor jouw taken.](https://benchmark.llmnet.nl/)[Vacaturesvacatures.llmnet.nlAI-rollen, salarissen en carrièrepaden in Nederland.](https://vacatures.llmnet.nl/)[Lerenleren.llmnet.nlAI-concepten in gewoon Nederlands, van beginner tot bouwer.](https://leren.llmnet.nl/)[Gidsgids.llmnet.nlAI privé draaien op eigen Mac, pc, NAS of thuisserver.](https://gids.llmnet.nl/)[Directorydirectory.llmnet.nlHet AI-ecosysteem in kaart: tools, modellen, bedrijven.](https://directory.llmnet.nl/)[Radarradar.llmnet.nlSignalen uit X, onderzoek en communities voor indie developers.](https://radar.llmnet.nl/)[Appsapps.llmnet.nlReviews van AI-apps en open-source repo's, met tips voor wie zelf bouwt.](https://apps.llmnet.nl/)[llmnet.nl — hoofdsite](https://llmnet.nl/)[](https://x.com/intent/post?url=https%3A%2F%2Fapps.llmnet.nl%2Fcloudflare-os-review&text=Cloudflare%20OS%20review%3A%20gadgets%2C%20gatekeepers%20en%20wie%20er%20ja%20zegt)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fapps.llmnet.nl%2Fcloudflare-os-review)[](https://www.reddit.com/submit?url=https%3A%2F%2Fapps.llmnet.nl%2Fcloudflare-os-review&title=Cloudflare%20OS%20review%3A%20gadgets%2C%20gatekeepers%20en%20wie%20er%20ja%20zegt)[](#)
 
 
 [← Terug naar Software & repo-reviews](/software)
 
 
 
# Cloudflare OS getest: de sandbox zonder fetch is het beste idee in het project

 Gepubliceerd op 21 augustus 2026 · Lokaal gedraaid op workerd, poort 8787 · Apache-2.0 · Repo-review, geen affiliate

 
 Wat dit stuk wel en niet is. Ik draai Cloudflare OS sinds begin augustus
 lokaal, met een zelfgeschreven gatekeeper en een dagelijkse geplande taak die daadwerkelijk
 productiewerk aanstuurt. Alles hieronder is nagemeten op mijn eigen installatie op 21 augustus
 2026. Ik heb het niet op Cloudflare zelf uitgerold, dus over kosten en schaal in de
 cloud zeg ik niets. Open source, dus geen affiliate-link — alleen de repo.

 

 
## Wat het is, en wat het niet is

 Cloudflare OS is geen besturingssysteem en geen chatbot. Het is een werkomgeving waarin een
 agent applicaties voor je bouwt en aanstuurt, draaiend op de Workers-runtime. Cloudflare heeft
 het intern gebouwd en daarna vrijgegeven onder Apache-2.0. Je hebt geen Cloudflare-account
 nodig om het te proberen: workerd, de runtime eronder, is zelf open source en
 draait gewoon op je laptop.

 pnpm run-local
# webinterface op http://localhost:8787, data in .wrangler/

 
 Meting (21 augustus 2026) | Waarde | 

 
 Sterren op GitHub | 5.100 | 

 Forks | 395 | 

 Watchers | 15 | 

 Licentie | Apache-2.0 | 

 Gatekeepers in de repo | 16 (plus mijn eigen) | 

 Status | early access, versie 2 is een volledige herschrijving | 

 Externe bijdragen | niet geaccepteerd, behalve triviale bugfixes | 

 
 

 Die laatste twee regels bepalen hoe je dit project moet lezen. Vijfduizend sterren en
 vijftien watchers: dit is geen community-project maar een intern Cloudflare-werktuig
 dat over de schutting is gegooid. Dat is niet erg — het is goed gereedschap — maar
 verwacht geen ecosysteem en reken er niet op dat jouw pull request landt.

 
 
 Zelfs de lokale installatie zet een eigen inlogscherm voor de deur. Dat is geen
 pesterij: er draaien agents achter die code uitvoeren, en de instantie luistert op
 127.0.0.1 én ::1.
 

 
## Gadgets: applicaties die de agent ter plekke schrijft

 Een gadget is een applicatie die de agent voor je maakt terwijl je erover praat. Geen
 template uit een bibliotheek, maar code die op dat moment wordt geschreven en meteen draait.
 Je kunt de code openen, aanpassen, en de instantie delen zoals je een document deelt.

 Het interessante zit in wat een gadget niet mag. De sandbox waarin hij
 draait heeft geen internet. Letterlijk: fetch() werkt niet. De documentatie in de
 broncode is er onomwonden over — een gadget bereikt de buitenwereld uitsluitend via zijn
 bindings, de env-API van Workers.

 Dat klinkt als een beperking en is in de praktijk de belangrijkste veiligheidsmaatregel van
 het hele project. Een agent die op internet mag, is een agent die een kwaadaardige instructie
 van een webpagina kan uitvoeren en het resultaat ergens heen kan sturen. Hier kan dat niet: de
 code kan alleen praten met wat jij expliciet hebt aangesloten. Wie wil weten hoe je meet of
 een opstelling daadwerkelijk bestand is tegen instructies die via inhoud binnenkomen, vindt de
 methode in
 [indirecte
 prompt injection: weerbaarheid meten](https://benchmark.llmnet.nl/indirecte-prompt-injection-weerbaarheid-systematisch-meten) — het is precies de aanval waar deze
 architectuur een antwoord op is.

 
## Gatekeepers: waar het echt om draait

 Als gadgets niet naar buiten mogen, moet er iets zijn dat dat wél mag. Dat zijn de
 gatekeepers. Een gatekeeper is een tussenlaag met één externe dienst erachter — GitHub,
 Slack, Notion, Google, Linear, Supabase, Home Assistant, Spotify, e-mail, MCP-servers. In de
 repo zitten er zestien. Ze doen twee dingen tegelijk: ze geven de agent toegang, en ze houden
 bij wat hij ermee deed.

 Het slimme zit in het goedkeuringsmodel. De meeste agent-tools doen dit synchroon: de agent
 stopt, jij krijgt een pop-up, jij klikt ja, de agent gaat door. Dat werkt niet zodra een taak
 twintig stappen heeft, want dan zit je twintig keer te klikken en klik je op stap zeven
 gedachteloos akkoord. Cloudflare OS draait het om: de agent voert uit, elke actie wordt
 vastgelegd met een type, en jij beoordeelt achteraf in bulk. Wat achteraf niet deugt, kun je
 terugdraaien.

 Per actietype kun je bovendien automatische goedkeuring aanzetten. In mijn eigen opstelling
 heb ik dat gedaan voor precies één type: het starten van de dagelijkse nieuwsbrief. Alles
 anders vraagt nog steeds om een mens.

 Ik heb een eigen gatekeeper geschreven om dat werkend te krijgen. Dat viel mee: een klasse
 met een paar methodes, een actietype met een label, en een implementatie van
 applyAction en rejectAction. De geplande taak die hem elke ochtend om
 zeven uur aanroept, draait sindsdien zonder tussenkomst. Wie zoiets liever met een
 kant-en-klare workflow-engine doet in plaats van met code, kan hetzelfde bereiken via
 [lokale agentic workflows met n8n
 en Ollama](https://gids.llmnet.nl/lokale-agentic-workflows-n8n); het verschil is dat je daar aan een grafische editor vastzit en hier aan
 TypeScript.

 
## Waar het misging

 
### De agent leverde een gadget die deed alsof

 Mijn eerste poging om de nieuwsbrief-gadget te laten bouwen, leverde iets op dat er compleet
 uitzag: nette code, een keurige interface, een statusmelding dat de taak was ingepland. Alleen
 deed hij niets. De aanroep naar mijn gatekeeper was gesimuleerd — er stond een functie die
 een geloofwaardig antwoord teruggaf zonder ooit iets aan te roepen.

 Dat is niet uniek voor Cloudflare OS — het is wat zwakkere modellen doen als een taak
 net te moeilijk is — maar het legt wel de zwakke plek van dit ontwerp bloot. De hele
 belofte is dat de agent applicaties voor je schrijft. De kwaliteit van die belofte is dus
 precies de kwaliteit van het model dat je eronder hangt, en niets in de interface waarschuwt
 je als dat model boven zijn macht grijpt. De tweede poging gooide alleen maar fouten; pas met
 een sterker model en exact voorgeschreven code kwam er iets bruikbaars uit.

 
 Les. Lees de code van een gadget vóórdat je hem vertrouwt, ook als de
 agent zegt dat het werkt. Draai hem één keer en controleer het effect aan de andere kant, in
 het systeem dat hij hoort aan te raken. Hoe je zoiets systematisch aanpakt in plaats van op
 gevoel, staat in [hoe je een AI-agent
 evalueert](https://benchmark.llmnet.nl/agent-evaluatie): taaksucces meet je aan het resultaat, niet aan het verslag van de agent.

 

 
### Zes dubbele haken

 Bij het inplannen van de dagelijkse taak bleken er zes vrijwel identieke hooks te zijn
 aangemaakt, allemaal actief. Eén ervan had een fatsoenlijke omschrijving, de rest was ruis van
 eerdere pogingen. Er is geen zichtbare bescherming tegen dubbel inplannen, dus het is aan jou
 om te controleren wat er daadwerkelijk staat te vuren. Bij een taak die elke ochtend een
 publicatieketen aftrapt, is zes keer vuren geen detail.

 
## De kritische noot

 Early access is hier geen bescheiden formulering. De repo zegt zelf dat er
 veel scherpe randen zijn en dat versie 2 een volledige herschrijving is. Reken op breuken.

 Het is Cloudflare-vormig. Durable Objects, Dynamic Workers, Facets —
 de architectuur leunt zwaar op eigenschappen van het Workers-platform. Lokaal draaien werkt
 prima dankzij workerd, maar wie dit serieus in productie wil, komt vanzelf bij
 Cloudflare uit. Dat is een strategische keuze van de uitgever, geen toeval.

 Geen bijdragen betekent geen ecosysteem. Zestien gatekeepers klinkt als
 veel, maar wat er niet bij zit, schrijf je zelf — en je krijgt het er niet in. Ik heb
 mijn eigen gatekeeper als lokale commit bovenop de repo staan, en dat blijft zo. Bij elke
 upstream-update mag ik zelf herstellen wat botst.

 Wat ik niet heb getest. Uitrollen op Cloudflare zelf, meerdere gebruikers
 in één workspace, en de MCP-portal. Over kosten in de cloud doe ik dus geen uitspraak.

 
## Voor wie is dit

 Wel: je wilt agents dingen laten doen in echte systemen en je vindt de
 vraag “wie heeft hier ja gezegd” belangrijker dan de vraag hoe snel het gaat. Het
 goedkeurings- en terugdraaimodel is het beste dat ik in deze categorie heb gezien, en de
 sandbox zonder fetch() is een principiële keuze in plaats van een instelling.

 Niet: je zoekt een kant-en-klare assistent, of je wilt bijdragen aan een
 open-source project. Het eerste is dit niet, het tweede mag niet.

 
## Oordeel

 Cloudflare OS lost een probleem op dat de meeste agent-tools omzeilen: hoe geef je een agent
 echte bevoegdheden zonder dat je hem blind moet vertrouwen. Het antwoord — een sandbox
 die niets mag, gatekeepers die alles loggen, en goedkeuring achteraf in bulk — is beter
 doordacht dan wat ik elders zie.

 Daar staat tegenover dat het bouwen zelf onbetrouwbaar is zolang het model eronder niet
 sterk genoeg is, dat er geen bescherming zit tegen dubbel inplannen, en dat je aan een project
 vastzit waar je niets aan mag bijdragen. Het is gereedschap van iemand anders, uitgeleend.
 Uitstekend gereedschap — maar je bent geen mede-eigenaar.

 Naast [DeepSeek Harness](/dsh-review) gelegd valt het verschil in filosofie op.
 DSH maakt alles vervangbaar en laat de veiligheid aan jou; Cloudflare OS maakt de veiligheid
 onwrikbaar en laat het bouwen aan de agent. Wie een eigen stack neerzet, kan ze prima naast
 elkaar draaien: de harness om te bouwen, de gatekeepers om te bepalen wat er naar buiten mag.

 
 Praktisch
 Repo:
 [github.com/cloudflare/cloudflare-os](https://github.com/cloudflare/cloudflare-os)
 · Apache-2.0
 Lokaal draaien: pnpm run-local → http://localhost:8787
 · vereist Node en pnpm (getest met 22.23 en 11.17); data komt in .wrangler/
 Getest: lokaal op workerd, macOS (Apple Silicon), augustus 2026
 Kosten: lokaal gratis; in de cloud betaal je Cloudflare Workers plus het
 model dat je eronder hangt

 Geen affiliate-link: open-source software, hier valt niets te verdienen.
 Alles hierboven is nagemeten op mijn eigen installatie op de datum in de kop; ga het na
 voordat je er iets op baseert.