Gadgets: Personal app vibe coding that is actually safe — Kenton Varda, Cloudflare
Description
*Note: Kenton has just released Cloudflare OS today: https://x.com/KentonVarda/status/2084990137180590572 This talk was recorded a month prior to launch.* Claude needed a strikethrough the slide app did not have, so it added one to the app. Asked to build a deck from a Google doc, it also added text centering and a box that accepts raw SVG, then generated the SVG for a diagram the app could not otherwise draw. That is Kenton Varda's argument in a single move. Software today ships from a developer to users whose feature requests die in Jira, and the escape hatch developers reach for is a plugin architecture rewrite that takes years and never lands. If a user's own agent can add the feature, the core app stays clean and nobody waits. Nothing in current infrastructure supports that. Mobile platforms will not run unsigned code, and 25 years of cloud architecture put one blessed version of every app on the developer's server. Gadgets is his answer, built on Cloudflare Workers with no containers and no database. Each gadget is a single instance of an app, one deck or one board, and sharing is implemented by the platform so the app itself cannot get access control wrong. The UI runs in a null origin iframe that can only postMessage to its parent, over a Cap'n Web RPC session to server code in a dynamic worker sandbox, so an XSS bug in vibecoded code has nothing left to leak. The whole demo ran locally on workerd, so a dead conference network cost him only the one call that needed a model. Speaker info: - https://x.com/KentonVarda - https://lanparty.house - https://github.com/cloudflare/workerd Timestamps: 0:00 - Personal AI codegen breaks cloud infrastructure 1:16 - How feature requests die today 2:35 - The plugin system rewrite trap 3:27 - What if users could add their own features 5:11 - Gatekeeping, and why the web is the escape hatch 7:11 - Kenton Varda and Cloudflare Workers 8:39 - Gadgets as an office suite, not a deploy target 9:58 - Blueprints and the slide bui
Summary
Generated by gpt-5.6-terraAt-a-Glance
- Verdict: Watch fully
- Core thesis: Personalized, AI-generated applications require a new infrastructure model in which each user's app instance is safely modifiable, isolated, shareable, and governed by the platform rather than deployed as a single centrally controlled web application.
- Why it matters: This is a concrete architecture for enabling user- and agent-authored software without granting arbitrary generated code access to cookies, credentials, networks, or shared application data.
- Best use: Use it as a design reference for an agent-native personal-app control plane: per-object app instances, capability-limited execution, platform-owned sharing, and explicit connector boundaries.
Executive Summary
Kenton Varda argues that conventional cloud delivery is fundamentally mismatched to personal AI code generation. Today, developers ship one canonical version of a hosted application to all users; feature requests either bloat that shared product or wait indefinitely for an extensibility rewrite. His alternative is for users to ask an agent to alter an app for their own needs, keeping the original product core clean while allowing individualized functionality.
The proposed product model, called Gadgets, resembles Google Docs more than a typical vibe-coding deployment platform. A user owns many small application instances—such as a slide deck, whiteboard, email filter, or pull-request sorter—rather than deploying broadly accessible apps. Useful gadget code can be exported without its data as a blueprint, then instantiated by others. Each instance maps to one shareable object, allowing the platform to own sharing and access control instead of trusting generated application code to implement them correctly.
The key technical claim is that generated code can be made substantially safer by removing ambient authority. The UI runs in a null-origin iframe under restrictive CSP; it can communicate only by postMessage to a platform parent. Server code runs as a Cloudflare Durable Object in a Dynamic Worker sandbox, likewise unable to communicate freely with the outside world. Client and server can interact with each other to render the gadget, but neither is meant to access cookies or arbitrary network resources.
This is strategically high-signal for agent systems because Varda frames safety as an architectural containment problem, not a code-review or prompt-quality problem. The presentation is also a product preview rather than a released framework: external-service access is mentioned but not explained, and Gadgets was not open-sourced at the time of the talk despite an expected release "soon."
Key Takeaways
- Claim: Personal AI coding breaks the standard model of deploying one centrally operated application version for every user. | Evidence: Varda contrasts the conventional flow—users request features, product managers triage them, and developers accumulate special-case logic or stall on a plugin-system rewrite—with a model where a user asks an agent to implement a feature only for that user's copy of the app. | Implication: For personal and internal tools, treat customization as a first-class runtime operation on an owned app instance rather than as a contribution to a shared codebase. | Caveat: The argument assumes that many requested features are genuinely local rather than requiring shared product behavior, centralized governance, or coordinated data-model changes.
- Claim: A personal-app platform should organize software as many individual, stateful, shareable objects rather than as generic web deployments. | Evidence: Gadgets is described as an office-suite-like environment: users have hundreds or thousands of individual apps, including one-shot-generated whiteboards, a Spanish-email filter, a PR sorter, and instances of document editor, Kanban, and slide-builder blueprints. | Implication: The primary product primitive should be an app instance bound to a specific user artifact or workflow, with its own code and data, rather than a URL pointing to a single multi-tenant application.
- Claim: Blueprints separate reusable application logic from private user data, enabling distribution without converting every custom gadget into a centrally managed SaaS product. | Evidence: A blueprint is created by exporting a useful gadget's code without its data; another person can instantiate a new gadget from that blueprint. Varda uses a slide builder, Kanban board, and document editor as examples. | Implication: A reusable-agent-app ecosystem needs an explicit code/data split and lifecycle policy; copying a prompt or publishing a hosted app is not an adequate substitute. | Caveat: The talk does not cover blueprint provenance, versioning, dependency review, malware scanning, or how updates propagate to already-instantiated gadgets.
- Claim: Platform-level sharing and access control are safer when each app instance represents exactly one shareable object. | Evidence: A slide-builder instance is only one slide deck; creating multiple decks means creating multiple gadget instances. Because the shareable unit and app instance are the same, the platform can provide a Google-Docs-style sharing dialog and enforce permissions outside generated code. | Implication: Model the authorization boundary around a concrete artifact—one deck, board, workflow, or household automation domain—so agents do not need to invent ACL logic in generated applications.
- Claim: The proposed safety model relies on isolation and removal of ambient authority, making classes of client-side generated-code flaws non-exfiltrating by default. | Evidence: The gadget UI runs in a null-origin iframe sandbox with a restrictive Content Security Policy and cannot access cookies or the wider world; its only communication path is postMessage to the parent. That path establishes a Cap'n Web RPC session to the gadget's server code. | Implication: For agent-generated UIs, do not rely on generated-code correctness for containment. Start with no direct network, cookie, credential, or parent-context access, then expose narrowly mediated capabilities. | Caveat: Varda's statement that no security bug in gadget code matters is bounded by this restricted environment. The security of the parent platform, RPC interface, authorization layer, and any external-service connector remains critical, and those connector mechanisms are not detailed.
- Claim: The server-side half of the gadget must be confined as tightly as the generated frontend. | Evidence: Each gadget's backend is a Durable Object on Cloudflare Workers running in a Dynamic Worker sandbox; Varda says it too is prevented from communicating with the rest of the world, so the generated client and server can only talk to each other and produce the user interface. | Implication: A secure personal-app runtime needs end-to-end containment: sandboxing only the browser UI is insufficient if generated backend code receives unrestricted network or data access. | Caveat: The presentation says a separate system exists for safely connecting gadgets to external services, but provides no implementation details, permission model, or revocation behavior.
- Claim: Complex personal apps can run without containers or a conventional database, including in a self-hosted local environment. | Evidence: Varda states that Gadgets, other than the LLM, is built on Cloudflare Workers using Dynamic Workers and Durable Objects rather than containers and a separate database. The demo ran locally on his laptop through open-source workerd, and he cites Home Assistant and Spotify connectors as a motivation for running it in his basement. | Implication: For local-first or home-agent use cases, a sandboxed edge-runtime-style execution environment may be a more coherent foundation than assembling containers, databases, and browser sandboxes independently. | Caveat: This is a platform-specific implementation claim, not evidence that Durable Objects are universally sufficient for all data, compute, observability, compliance, or multi-region requirements.
Detailed Brief
Agent-driven application evolution, not merely agent-driven content editing
- Claims: Every gadget automatically integrates with an agent, allowing the agent to modify both an artifact and the application that edits the artifact.; The important capability is not just generating a new app from a prompt; it is allowing the agent to inspect existing gadget code, recognize a missing capability, and extend the software in place.
- Evidence: For his presentation, Varda gave Claude a Google Doc specifying desired slides and explicitly authorized it to add slide-builder features if needed.; Claude identified missing strikethrough and centering support, then added them.; When asked for an arbitrary cloud drawing that the slide app could not represent with boxes and arrows, Claude added an SVG insertion feature and generated the SVG itself.
- Caveats: The SVG example demonstrates useful agent adaptation, but it also illustrates why the runtime must assume generated feature code and generated content can be hostile or unsafe.; The talk does not address regression testing, UX review, rollback, audit trails, or user approval thresholds for agent-initiated changes to an existing gadget.
- Implications: The valuable long-term primitive is a persistent, inspectable app artifact that an agent can evolve incrementally, not a disposable one-shot generation.; An operator should separate permissions to edit user data from permissions to extend an app's implementation, even if an agent can perform both.
Project maturity and release status
- Claims: Gadgets originated as Varda's side project on top of Cloudflare Workers but had recently become a more serious internal Cloudflare initiative.; The expected immediate open-source release was delayed to support a more deliberate release process.
- Evidence: Varda says Cloudflare CTO Dane Knecht asked him not to "yeet" the project to GitHub and instead to release it more carefully and intentionally.; He says the code would be released soon, but it was not available at the time of the talk.
- Caveats: There is no public repository, roadmap, supported API, security documentation, or independently verifiable implementation in the transcript.; The on-stage prompt demo failed because the internet was unavailable, so the presentation's working evidence is primarily architectural explanation and preexisting examples.
- Implications: Track the eventual release as a potentially important reference implementation, but do not plan around its availability or infer production readiness from the talk.; The strongest transferable value now is the architecture and authority model, rather than any specific Cloudflare product commitment.
Notable Concepts & Terms
- Gadgets: Varda's proposed personal-app environment, where each application instance is a distinct, editable, stateful object akin to a Google Doc rather than a conventional deployed web app.
- Blueprints: Reusable gadget code exported without its instance data, allowing others to create independent app instances from a common template.
- Per-object app instance: The design choice that one app instance corresponds to one concrete artifact, such as one slide deck, enabling platform-controlled sharing and authorization.
- Null-origin iframe sandbox: The client isolation mechanism: generated UI has no normal web origin, cannot access cookies, and is restricted by Content Security Policy.
- Cap'n Web RPC: The postMessage-mediated RPC path used to connect the sandboxed gadget frontend to its sandboxed server component.
- Durable Objects: Cloudflare Workers' stateful server primitive, used here as the gadget backend rather than a separate conventional database.
- Dynamic Workers: The server-side execution sandbox Varda describes for gadget code, intended to prevent generated backend logic from freely reaching external systems.
- workerd: Cloudflare's open-source Workers runtime, which Varda says enabled Gadgets to run locally on his laptop and could support self-hosted home-automation use cases.
Operator Notes / Why Ken Should Care
- Evaluate personal-agent app architectures against an explicit no-ambient-authority checklist: no inherited cookies, no direct network access, no unconstrained credentials, and no generated authorization logic.
- Adopt a per-artifact tenancy model for collaborative agent apps, with platform-owned sharing, permissions, audit logging, and revocation rather than application-authored ACLs.
- Define blueprint governance before permitting reuse: publisher identity, immutable versions, dependency inventory, review/scanning, update policy, and a kill/revocation path.
- Treat external connectors as the highest-risk layer; require granular capability grants, scoped tokens, user-visible authorization, and revocation before allowing generated code to control services such as Home Assistant or Spotify.
- Monitor the Gadgets/workerd release for implementation details of connector mediation and the Cap'n Web RPC boundary; those omitted pieces determine whether the claimed containment model holds in practice.
Source/Metadata
- Title: Gadgets: Personal app vibe coding that is actually safe — Kenton Varda, Cloudflare
- Transcript words: 5783
- Duration seconds: 1133
- Timestamp note: No timestamps or chapters were present in the supplied transcript; substantial portions of the transcript are duplicated.
Transcript
Okay. Hi. All right. I've got a lot to talk about, so I'm going to launch right into it here. SWIX says that you only get to make one point at every talk, one key takeaway. I figured I'd just lead with that. My key point is personal AI code gen breaks traditional cloud infrastructure. And to clarify what I mean about that, the word personal here is doing a lot of work. It's load-bearing, as Claude would say. My point is that if we want to see this future where everyone has personal apps and can personalize the apps that they run, the infrastructure we're using today for software in general is not the right thing, and we need something completely different. To explain what I mean, think about the way that software is produced and distributed today. You have a developer in an ivory tower who builds an app and then sends it down to the people, the users who use the app. Many of them are happy with it, but some of them are not. Some of them say, this app needs some additional features for my use case. And so they go to the developer and they say, oh great developer, will you please grant my feature requests? Your app is literally unusable without it. And so then the developer's representative, the product manager, takes these feature requests and files them into Jira, where they are never seen again. But sometimes, sometimes the product manager sees the feature request and says, ah, I want that too. And then that feature request goes onto the roadmap and the developer works on it. And the developer is implementing all these features, features that each one is only used by a small subset of users. And each one is adding all these if statements to their code and making things messy. And they don't like it because the code base is becoming a mess. And each of these features is really boring to implement. And the developer says, ah, I know what I need to do. We need a rewrite. We need a new architecture that has a plug-in system. And then every one of these features can be a plug-in, and it can be nice and clean and easy to build, and the core can stay clean. And so the developer goes off and starts working on the new architecture with the plug-in system. And there are still feature requests coming in. And the developer says, well, we can't do those features yet because, ah, we need the plug-in system. This will be so much easier once we have the plug-in system. And if we do it now, we're just delaying that, and we'll just have to redo it later anyway. And so the years go by, and the new architecture is not ready yet, and none of the features are being implemented. And people are saying, what are they doing? This developer has given up their product, and everybody is sad. AI seems to present a new alternative to this. What if the developer could create their app, the first version of their app, give it to the users, and the users, if they need a new feature, could ask their AI agent to write that feature just for them, add it to the app. Then everyone gets the features they need. No one is bogged down in everyone else's features. And the developer gets to keep the core app nice and clean and beautiful. But there's a problem with this, which is that none of the infrastructure we build software on today is remotely designed for this. You've got Apple and Google for the past 15 years gatekeeping their systems to the point where there's five companies that can build mobile apps now because everyone else has been banned. And it's almost easier in the United States to buy a gun than it is to get access to your own phone to install unsigned software. You go to Google and you say, I want to install unsigned software, and now they're going to say, oh, whoa, hold on, buddy. You seem upset. You should go home and think about this. If you still want that unsigned software in 24 hours, then you can come back and talk to us. Fortunately, we have a workaround for all of that, which is the web. On the web, everyone can build whatever they want, and it turns out it's fine. It's not the security disaster that Apple and Google keep telling us would happen. So you can build whatever you want on the web, but there's a different problem on the web, which is that for the past 25 years of cloud architecture, we've been running in the wrong direction. When you distribute a web app, you run it on your own server. Put it on your server, and then users send requests to your server, where the one version of your app, the one blessed version, runs for every single user. And so that's convenient for developers. That's why we've done it, so the developer can make sure things stay updated and everyone's on the same version. But it obviously means that users cannot customize their apps. Last year, vibe coding comes along, and we have all these vibe coding platforms out there. Most of them are targeting web apps because that's the easy thing to target, but they're all targeting this existing infrastructure, which is actually not the right way to do it. We need something entirely different, and hence my point. Do you like how the word breaks kind of wiggles every now and then? That was something Claude put in there, and it was so stupid, I just had to keep it. I want to know where in Claude's training data it learned that you could make words wiggle to give them emphasis, because I understand the red, I understand the underline, but the wiggle, I don't think that's from humans. I think that's an AI original. This is ASI, folks, beyond my puny human brain's ability to comprehend. Anyway, so you might be wondering at this point, who is this guy who hasn't introduced himself up on stage, giving a Richard Stallman-esque rant about how we should have the freedom to modify our own software, and what does he know about cloud infrastructure? So, I'm Kenton Varda. I created Cloudflare Workers. I started the project back in 2017 when I joined Cloudflare. I am still the lead engineer today. It now is a serverless application hosting platform. We have millions of developers. We serve trillions of requests per day. But what I'm going to talk to you a little bit about today is a side project I've been working on on top of Workers, which is designed to, is my exploration in how to solve this problem. This thing you're looking at right now is actually a little app that I created in this platform. But going to the front page here, you have your vibe code prompt. These things are a dime a dozen. I've seen this before, but I'm just going to put in a little prompt to show that it works. Make a silly counter app. Silly max it. Someone's silly. All right. But I'm not actually going to sit here and watch it. Oh no, it said error. Yep. The internet doesn't work. That's okay. That's not the most important part of my talk. What I want you to understand about this environment is this is not your typical vibe coding environment where you're deploying apps to a web page. You need to think about it more like an office suite. So think about Google Docs. You open Google Docs, you have a bunch of documents, hundreds, maybe thousands of documents. You open one, you edit it, you share it with people. This is the same thing, except instead of documents, you have gadgets. And each gadget is an application with code. They can all be different code. I have an app here which is a collaborative whiteboard app. This is a one-shot prompt. I have an app here which, so I get a lot of email in Spanish. It's a long story. I don't know Spanish, but I need help filtering all the Spanish email. So I made a little app to help me do that, a gadget. I have a gadget to help me sort pull requests that I need to review on GitHub. Google Docs. You open Google Docs, you have a bunch of documents, hundreds, maybe thousands of documents. You open one, you edit it, you share it with people. This is the same thing, except instead of documents, you have gadgets. And each gadget is an application with code. They can all be different code. I have an app here, which is a collaborative whiteboard app. This is a one-shot prompt. I have an app here, so I get a lot of email in Spanish. It's a long story. I don't know Spanish, but I need help filtering all the Spanish email. So I made a little app to help me do that. A gadget. I have a gadget to help me sort pull requests that I need to review on GitHub. But those are things that I just Vibe coded from scratch. But we also have this concept over here of blueprints. And a blueprint is someone made a gadget and they decided that it was useful and they took a blueprint of it, which is just taking the code, exporting the code without the data, which they can then share with someone else. And then other people can instantiate gadgets from these blueprints. So we have a document editor app here, a Kanban board, and a slide builder. Typical office apps. I'm going to, so this slide builder was built by my colleague Phillip here, who's a product manager at Cloudflare. And of course, these days, all product managers are also prolific engineers. So he vibed this in an afternoon, I believe, but if I instantiate this gadget, I get this nice little slide deck. It has things, I can edit it, and so on. Yay. And if I shared it, it would, well, an important point here is that when I instantiate this app, it is only for one slide deck. If I want multiple slide decks, I make multiple instances of the gadget, one for each. And the reason for that is that all gadgets are shareable and you can collaborate with other people on them. And the sharing model is implemented by the platform instead of by the app itself. So if I click up here, I get a share dialogue, like a Google Docs share dialogue, and create a share link and send it to people. And because each gadget is just the one thing that you want to share, that means that the platform can implement the sharing model and the access control such that the gadget itself can't possibly get that wrong. So I'm going to go over to another instance of the same slides app. This is the slides I originally wrote for this talk, which yesterday I decided were trash and I threw them all away and rewrote it. But the reason they're bad is entirely my fault. It's not Phillip's fault. It's not the software's fault. But this can still serve as an example to demonstrate some of what you can do on this platform. So if I click on here, I can see the conversation. Of course, I didn't edit the slides myself by hand. I asked the agent to make them for me, right? And every app in this platform automatically integrates with agents so that you can do that. And so what I did is I gave Claude a link to this document, this Google doc, where I had described all of the gadgets that I wanted, or all the slides that I wanted in my presentation. And crucially, though, this is the interesting point. I said, if you need to add any new features to the slides app itself to support some of these slides, feel free to do so. And it did. Claude read all the code for the app and read my doc and said, yes, actually, let's see, slide three needs strikethrough formatting. That's not implemented. We can add that. Some of the slides require things to be centered. And I guess Phillip's design taste is too good for centering text. But my more pedestrian taste called for some centering, and that's okay. Claude can add that. More interestingly, slides five and six here. So I asked for this really crappy diagram of the cloud, right? And the app didn't support arbitrary diagrams. It supported box diagrams and arrows and such, but not an arbitrary drawing like this. And so Claude said, okay, that's okay. We can add a feature. We'll add a feature that allows you to insert a bunch of SVG. Just paste it into this box here, and now it becomes part of the slide. And now that's not very useful for any human, but it was perfectly useful for Claude, who then generated the SVG. Now at this point, you might be looking at this and saying, that's a little scary. SVG can contain JavaScript. Are there XSS bugs here? And the answer to that is it doesn't really matter because of the way this environment is set up. So the UI that you see for the app here is running inside a null origin iframe sandbox, with content security policy set so that it basically cannot talk to anything, any of the rest of the world, can't access any cookies, and so on. The only thing it can do is post message to the parent frame. And through that post message channel, we set up a captain web RPC session, which forwards onto the server and all the way back to the server code for this gadget, which is this code here, which is written as a durable object on Cloudflare workers. And basically that means this server code runs in a dynamic worker sandbox on the server side where it too is prevented from talking to any of the rest of the world. So now we've set up this environment where there's a vibe coded client and a vibe coded server, and they can only talk to each other and produce the UI for the user. And so if you have an XSS bug, it actually doesn't end up mattering because these can't leak anything. They're prevented from doing so. And basically, there is no security bug you can have in this code that matters. And that makes it safe to go and do things. So there's a whole lot that I would like to talk about that I won't have time for here, unfortunately. So for instance, we created a whole system by which these apps can talk to external services in a safe way, but I could give two more talks about that. We created, there's a lot of stuff here. The points that I want to make in the time that I have left, though, is everything you see here, everything except for the LLM, is built on Cloudflare workers. A lot of people don't know this, but you can actually build complex apps on workers. There are no containers involved here. There's just dynamic workers. There's no database involved. It just uses durable objects. And furthermore, all of this is actually running locally on my laptop, which is why it doesn't matter that the internet didn't work because this is all running on worker D, which is our open source runtime. A lot of people don't know this, the Cloudflare workers runtime is open source. You can self host it. And I'm excited about that because we have in here a home assistant connector and a Spotify connector, and I want to run this in my basement and use it to do home automation tasks. So this is where I have to give a little bit of an apology. A couple of months ago when I submitted the proposal for this talk, this was a side project I was working on. And the plan was I was going to come here and I was going to present it. And then I was just at the end of the talk going to yeet it onto GitHub so that everyone could go and download and play with it themselves. In the last couple of weeks, there's been a lot of excitement inside Cloudflare and this has become a more serious project. And so last Thursday, Dane, our CTO, pulled me into a room and said, Kenton, I don't think you should yeet this. I don't think this is yeet material. I think we need to be more careful and disciplined And use it to do home automation tasks. So this is where I have to give a little apology. A couple of months ago, when I submitted the proposal for this talk, this was a side project I was working on. The plan was that I was going to come here and present it. Then, at the end of the talk, I was going to put it on GitHub so that everyone could download it and play with it themselves in the last couple of weeks. There’s been a lot of excitement inside Cloudflare, and this has become a more serious project. So last Thursday, Dane, our CTO, pulled me into a room and said, Kenton, I don't think you should do this. I don't think this is yeet material. I think we need to be more careful and disciplined and intentional about how we release this, so let's hold it off for a few weeks. I was pretty upset about that because I promised in the abstract that I was going to open source it, but sorry, that's not happening today. It will happen soon, though. I wish the silly counter worked because GPT makes some silly counters, but it's not a big deal. And that's all I got. Thank you. Thank you. system. And then every one of these features can be a plug-in and it can be nice and clean and easy to build and the core can stay clean. And so the developer goes off and starts working on the new architecture with the plug-in system. And there are still feature requests coming in. And the developer says, well, we can't do those features yet because, ah, we need the plug-in system. This will be so much easier once we have the plug-in system. And if we do it now, we're just delaying that and we'll just have to redo it later anyway. And so, um, the years go by and, ah, the new architecture is not ready yet. And none of the features are being implemented. And people are saying, what are they doing? This developer has given up their product and, ah, everybody is sad. So, AI seems to present a new alternative to this. What if, ah, the developer could create their app, the first version of their app, give it to the users, and the users, if they need a new feature, could say, I could ask their AI agent to write that feature just for them, add it to the app. Um, then everyone gets the features they need. No one is bogged down in everyone else's features. Uh, and the developer gets to keep the, the core app nice and clean and beautiful. But there's, ah, there's a problem with this, which is that none of the, the infrastructure we build software on today is, like, remotely designed for this. You've got, ah, Apple and Google for the past 15 years, ah, gatekeeping their systems to the point where there's, like, five companies that can build mobile apps now and, ah, because everyone else has been banned. Um, and it's almost, like, easier to, in the United States to buy a gun than it is to, like, get access to your own phone to install unsigned software. You go to Google and you say, I want to install unsigned software, and now they're going to say, oh, whoa, hold on, buddy. Ah, you seem upset. Ah, you should, ah, go home and think about this. Ah, if you still want that unsigned software in 24 hours, then you can come back and talk to us. Fortunately, we have a workaround for all of that, which is the web. On the web, everyone can build whatever they want, and it turns out it's fine. It's not the security disaster that Apple and Google keep telling us would happen. So, you can build whatever you want on the web, but there's a different problem on the web, which is that, for the past, ah, 25 years of, ah, cloud architecture, we've been running in the wrong direction. Ah, when you distribute a web app, you run it on your own server. Like, put it on your server, and then users send requests to your server, where the one version of your app, the one, ah, you know, blessed version runs, ah, for every single user. And so, that's convenient for developers. That's why we've done it, is so the developer can make sure things stay updated and everyone's on the same version. But, um, it obviously means that users cannot customize their apps. So, you know, last year, ah, vibe coding comes along, and we have all these vibe coding, um, platforms out there. And the, most of them are targeting web apps because that's the easy thing to target, but they're all targeting this existing infrastructure, which is actually, like, not the right way to do it. Um, we need something entirely different, and hence my point. Do you, ah, do you like how the word breaks kind of wiggles every now and then? That was, ah, that was something Claude put in there, and it was so stupid, I just had to keep it. Um, I want to know where in Claude's training data, it, ah, it learned that you could make words wiggle to give them emphasis, because, like, I, you know, I understand the red, I understand the underline, but, ah, the wiggle, like, I don't think that's, that's from humans. I think that's an AI original. This, this is ASI, folks, ah, you know, beyond my puny human brain's ability to comprehend. Um, anyway, ah, so you might be wondering at this point, like, who is this, this guy who hasn't introduced himself up on stage, um, giving a Richard Stallman-esque rant about how we should have the freedom to modify our own software, and what does he know about cloud infrastructure? So, I'm Kenton Varda. I created Cloudflare Workers. I started the project, um, back in 2017 when I joined Cloudflare. I am still the lead engineer today. Um, it now is, uh, you know, it's a serverless application hosting platform. We have millions of developers. We serve trillions of requests per day. But what I'm going to talk to you a little bit about today is, uh, sort of a side project I've been working on on top of workers, which is, um, uh, designed to, is my exploration and how to, uh, uh, solve this problem. So, uh, this thing you're looking at right now is actually a little app that I created in this platform. But, um, going to the, the front page here. So, you have your, your Vibe code prompt. You know, these things are a dime a dozen. Um, I've seen this before, but I'm just going to put in a little prompt to me to show that it works. Uh, make a silly counter app. Silly max it. Someone's silly. All right. But I'm not actually going to sit here and watch it. Oh, no, it said error. Yep. The internet doesn't work. That's okay. That's not the most important part of my talk. So, um, um, huh. So, what I, what I want you to understand about this environment is, uh, this is not like your typical Vibe coding environment where you're deploying apps to a web page. This is, um, uh, you need to think about more like, uh, like an office suite. So, think about Google Docs. You open Google Docs, you have a bunch of documents, hundreds, maybe thousands of documents. You open one, you edit it, you share it with people. This is the same thing, except instead of documents, you have gadgets. And each gadget is an application with code. They can all be different code. I have, um, I have an app here, which is like a collaborative whiteboard app. Like this is a one-shot prompt. Um, I have a, uh, an app here, which, so I get a lot of email in Spanish. It's a long story. I don't know Spanish, but I need help, like filtering all the Spanish email. So, I made a little app to help me do that. Uh, a gadget. Um, I have a gadget to help me sort, uh, pull requests that I need to, uh, review on GitHub. And, uh, but those are, you know, things that I just like Vibe coded from scratch. But we also have this concept over here of blueprints. And, um, a blueprint is someone made a gadget and they decided that it was useful and they took a blueprint of it, which is just taking the code, exporting the code without the data, which they can then share with someone else. And then other people can, uh, instantiate gadgets from these blueprints. So, um, we have like a, you know, document editor app here, a Kanban board and, um, a slide builder. So like, you know, typical office apps. Uh, I'm gonna, so, so this, this slide builder, um, was built by my colleague Phillip here, um, who's a product manager at Cloudflare. And of course, these days, all product managers are also prolific engineers. Um, so he, you know, he vibed this in an afternoon, I believe, but, uh, if I instantiate this gadget, I get this nice little slide deck. Um, you know, it has things I can edit it and so on. Yay. And if I shared it, it would, well, so an important point here is that when I instantiate this app, it is only for one slide deck. If I want multiple side decks, I make multiple instances of the gadget, uh, one for each. And the reason for that is that all gadgets are, um, shareable and, uh, you know, you can collaborate with other people on them. And the sharing model is implemented by the platform instead of by the app itself. So if I click up here, I get sort of a, uh, share dialogue, kind of like a Google Docs share dialogue and create a share link and send it to people. And, uh, because each gadget is just the one thing that you want to share, that means that the platform can implement the sharing model and the access control such that the gadget itself can't possibly get that wrong. So I'm going to go over to actually another instance of the same, uh, slides app. This is the, um, the slides I originally wrote for this talk, which yesterday I decided these slides were trash and I threw them all away and rewrote it. Um, but the, the reason they're bad is, is entirely my fault. It's not Phillip's fault. It's, uh, not the software's fault. Um, but this, this can still serve as an example, uh, to, to demonstrate some of what you can do on this platform. So if I, uh, click on here, I can see the conversation. You know, of course, I didn't edit the slides myself by hand. I asked the agent to make them for me, right? Um, and every app in this platform automatically integrates with agents so that you can do that. And so what I did is I gave Claude a link to this document, this Google doc, where I had described all of the gadgets that I wanted or the, all the slides that I wanted in my, um, in my presentation. And crucially though, this is the interesting point. I said, if you need, uh, if you need to add any new features to the slides app itself to support some of these slides, feel free to do so. And it did. Um, Claude read all the code for the app and read my doc and said, yes, actually, let's see, slide three needs a, uh, strikethrough formatting. That's not implemented. Um, we can add that. Um, some of the slides require things to be centered. And, you know, I guess Phillip's design taste is too good for centering text. Uh, but my more pedestrian taste called for some centering and that's okay. Claude can add that. Um, more interestingly, slides, uh, five and six here. So I asked for this like really crappy diagram of the cloud, right? And the, the app, um, didn't support sort of like arbitrary diagrams. It supported, you know, uh, box diagrams and arrows and such, but not an arbitrary drawing like this. And so Claude said, okay, that's okay. We can add a feature. We'll add a feature that allows, uh, you to insert a bunch of SVG. Just paste it into this box here. And now it becomes, uh, part of the slide. And now that's not very useful for any human, but it was perfectly useful for Claude who then generated the SVG. Now at this point, you might be looking at this and saying, that's a little scary. SVG can contain JavaScript. Uh, are there XSS bugs here? And the answer to that is, uh, it doesn't really matter because of the way this environment is set up. So the UI that you see for the app here is running inside a null origin iframe sandbox, um, with content security policy set so that it basically cannot talk to anything, any of the rest of the world, can't access any cookies, so on. Um, um, the only thing it can do is post message to the parent frame. And through that post message channel, we set up a, a captain web RPC, uh, session, which forwards onto the server and all the way back to the server code for this gadget, which is, uh, this code here, which is written as a durable object on Cloudflare workers. And, uh, basically that means, so, so this, this server code runs in a dynamic worker sandbox, uh, on the server side where it too is prevented from talking to any of the rest of the world. So now we've set up this environment where there's a vibe coded client and a vibe coded server, and they can only talk to each other and produce the UI, uh, for the user. And so if you have an XSS bug, it actually doesn't end up mattering because these can't leak anything, um, they're prevented from doing so. And it'll basically, there is no security bug you can have in this code that matters. Um, and that makes it safe to, you know, go and do things. So, uh, I, uh, there's a whole lot that I would like to talk about that I won't have time for here, unfortunately. So the, um, uh, so there, like, for instance, the, uh, we created a whole system by which these apps can talk to external services in a safe way, but I could give, you know, two more talks about that. Um, we created, um, uh, uh, there's a lot of stuff here. The, the points that I want to make in the time that I have left though is, so everything you see here is, uh, is built on, everything except for the LLM is built on Cloudflare workers. Um, a lot of people don't know this, but you can actually build complex apps on workers. There are no containers involved here. There's just dynamic workers. There are no, there's no database involved. It just uses durable objects. Um, and furthermore, all of this is actually running locally on my laptop, which is why it doesn't matter that, uh, the internet didn't work because, uh, so this is all running on, uh, worker D, which is our open source runtime. A lot of people don't know this, the Cloudflare workers runtime is open source. You can self host it. And I'm excited about that because we have in here a, uh, home assistant, uh, connector and a Spotify connector and I want to run this in my basement and, uh, use it to do home automation tasks. Um, so this is where though I have to give a little bit of an apology. Um, so a couple of months ago when I submitted the, the, uh, the proposal for this talk, this was like a side project I was working on. And the plan was I was going to come here and I was going to present it. And then I was just at the end of the talk and I eat it onto GitHub so that everyone could go and download and play with it themselves in the last couple of weeks. Um, there's been a lot of excitement inside Cloudflare and this has become a more serious project. And so last Thursday, Dane, our CTO pulled me, uh, into a room and said, Kenton, I don't think you should eat this. I don't think this is yeet material. I think we need a, uh, we need to be more careful and disciplined and intentional about how we release this. So let's hold it off for a few weeks. And I was pretty upset about that because I promised in the abstract that I was going to open source it, but sorry, uh, that's not happening today. It will happen soon though. Um, and I wish the silly counter worked because GPT makes some silly counters, but, um, oh, well, it's not a big deal. And that's, uh, that's all I got. Thank you. Thank you.