Why a Gadget Is Not Just Another SaaS App
Cloudflare OS makes the Gadget—not the chat message or the vendor account—the concrete unit of software ownership. This chapter follows a Gadget from creation through AI-assisted changes, persistent state, collaboration, and Blueprint publication. The goal is to make one distinction precise: what belongs to a running Gadget, what belongs to the code design copied by a Blueprint, and what a new user must supply before that copy becomes their own application.
A software instance with an owner
In ordinary SaaS, the service provider owns the running application. Users own their accounts and the content they put into the service, but the application itself is shared infrastructure. If the service adds a feature, the provider changes the central product and eventually makes that change available to everyone. If the service does not add the feature, a user generally has only workarounds, integrations, or a request sent into someone else’s roadmap.
Cloudflare OS starts from a different premise. When a user asks an agent to make a slide deck, a whiteboard, or a small issue dashboard, the result can be a Gadget: a private instance of an application running for that user or workspace. The repository describes the instance as isolated from other users’ instances and, importantly, as modifiable. If the application is missing a feature, the user can ask the agent to change the code of their copy.
That is why a Gadget is more than a saved prompt. A prompt records intent; a Gadget holds executable code, application state, and a user-facing interface. Its server side can keep persistent state in the platform’s stateful runtime. Its client side can render an interface in the browser. Its bindings determine which external resources the application can reach. These parts give a Gadget a lifecycle that resembles a small software product, even when one person created it in response to a single request.
The private instance changes the economics of customization. A central SaaS provider must decide whether a feature is valuable enough to build, test, support, and expose to every customer. A Gadget owner can ask an agent to solve a narrower local problem. That does not make the change free or automatically correct. The owner now has to live with the code, state, permissions, and future maintenance of that particular instance. The point is that the decision can be local instead of waiting for a platform-wide roadmap.
The office-suite comparison in the repository helps explain the intended experience. Users may have many Gadgets, create them on a whim, collaborate on them, and start from reusable designs. But the analogy has a sharp edge: a conventional office document mostly contains content, while a Gadget can contain the application that manages the content. Sharing one can therefore share behavior and authority, not only a file.
The first transition: from proposed idea to running Gadget
A Gadget can begin empty, or it can be created from an existing Blueprint. In either case, the important transition is from an idea that an agent is proposing to code that the workspace treats as the Gadget’s committed implementation. During creation and editing, the agent may write files, test behavior, and propose changes. Once the relevant changes are accepted, the Gadget has a committed code base that can be loaded as its running application.
This separation between proposed and committed code is not just an editor convenience. It gives the workspace a way to distinguish experimentation from the version that other sessions should treat as the application. A user can ask for a change without immediately turning every intermediate edit into a new shared runtime. The code can be inspected and revised before it becomes the mainline behavior of the Gadget.
The transition also establishes ownership of state. A running Gadget is not just a code snapshot. Its server-side runtime has private storage, and the state created while the Gadget operates belongs to that instance. A planning dashboard might store preferences, a whiteboard might store shapes, and a slide application might store the deck it is editing. The precise data model varies by Gadget, but the architectural rule is stable: the application’s code and its accumulated state are related without being the same thing.
Bindings are another separate layer. A Gadget may have a connection to an external resource, but that connection is not silently implied by the existence of a user account. The owner must wire a selected resource into the Gadget’s environment. A Gadget’s code can then use the binding under the interface exposed by the relevant Gatekeeper. Two Gadgets owned by the same person can be connected to different resources, or one can remain entirely local while another uses a service connection.
That separation makes the private-instance model meaningful. If code, state, and live connections were all copied together without distinction, “your own copy” would merely mean another name for inherited access. Cloudflare OS instead treats a copy as a new application instance that must be given its own authority.
What a Blueprint carries—and what it leaves behind
A Blueprint is the mechanism for sharing the design of a Gadget without sharing the owner’s live instance. It captures a snapshot of committed source code, metadata, and the requirements of the bindings that the code expects. It can record that the application needs a particular kind of Gatekeeper, an AI model, or an agent spawner. It can also carry descriptions and suggested values to help a consumer configure those requirements.
It does not carry the running Gadget’s private storage. It does not carry chat history or the edit history that led to the current source. It does not carry live service connections or credentials. Those exclusions are the boundary between publishing an application design and exporting someone’s authority.
A consumer who opens a Blueprint therefore enters a configuration step. For an external-service binding, they choose one of their own connected accounts and a matching resource. For an AI-model binding, they choose from the models available to them. For an agent-spawner binding, they choose the model or leave the spawner without one. The new Gadget is then initialized from the Blueprint’s code, but it gets its own storage, chat history, and bindings.
That lifecycle is easier to see as a state machine:
The last transition is deliberately not an update link. An existing Gadget created from a Blueprint does not automatically receive later changes to that Blueprint. A Blueprint can have newer versions, and a publisher can update the design, but the consumer’s instance remains its own code base unless someone chooses to change it. This preserves the ability to customize locally. It also means that the publisher cannot assume every copy has the same security fixes, behavior, or feature set.
The distinction becomes practical when an application depends on external data. Suppose a Blueprint describes a meeting-preparation Gadget that uses a document service. A consumer does not receive the publisher’s documents simply by instantiating the Blueprint. They must connect an account and select a resource they are authorized to use. The application design travels; the sensitive data path does not.
That rule also determines what the publisher can safely promise. A Blueprint can say that the Gadget expects a document connection, identify the kind of resource the code was designed to use, and offer a suggested value. It cannot make the publisher’s live document binding appear inside the consumer’s new instance. The consumer’s account and resource remain the authority behind the connection, which means the same code can be used with a different document, a different account, or no document at all.
The separation is important even when the two users are in the same organization. A reusable application may encode a useful workflow without being entitled to every record that workflow once touched. If the publisher’s Gadget prepared a briefing from private material, publishing its Blueprint does not publish that material. A consumer must independently configure access, and a later chapter will examine why a shared running Gadget requires still more care when it has already observed data.
It also clarifies what “version” means. A Blueprint may have a newer code version, but the consumer’s running Gadget has its own code history and state. Updating the published design does not silently overwrite local changes or migrate local storage. That is a benefit when the consumer has adapted the application to their own workflow. It is a cost when a security repair or important compatibility change needs to reach many independent instances.
The lifecycle is therefore better understood as a controlled fork than as a subscription. The source Gadget supplies a design; the Blueprint packages a selected code snapshot and the shape of its required capabilities; the consumer creates an instance and supplies the missing authority. After that point, the two instances can evolve separately. Their relationship is social and operational—people may choose to publish updates, compare changes, or rebuild from a newer version—not an automatic runtime dependency.
Why AI changes the meaning of a feature request
In a traditional product, a feature request points outward. The user describes a problem, and the request enters a queue controlled by the product’s owner. In a Gadget, the same request can point inward: change this instance so it behaves the way I need.
That changes both the opportunity and the risk. The opportunity is direct adaptation. A sales team may want a custom briefing tool, an engineer may want a narrow repository dashboard, or a group may want a collaborative planning surface that no general-purpose product offers. The agent can create a first version, run it, observe failures, and revise the code in the context where the application will be used.
The risk is that the result is now software someone must understand and maintain. A centrally hosted product concentrates responsibility for deployment, upgrades, and common behavior in one provider. A population of private Gadgets distributes those responsibilities across owners and Blueprint consumers. A local modification can solve a real problem quickly, but it can also diverge from later improvements or preserve a bug that a centralized provider would have fixed once.
Cloudflare OS’s model is therefore not simply “AI makes software easier.” It is “AI makes local software creation plausible enough that the ownership boundary becomes important again.” The user is closer to the software, but closeness does not eliminate the need for review. It makes questions about code provenance, bindings, state, and updates more immediate.
The trade-off: control instead of uniformity
Sharing code rather than a hosted service gives the consumer more control. They can inspect the design, ask their own agent to adapt it, and connect it to resources under their own account. The publisher can distribute a reusable application without operating a public service for every consumer. For organizations that want internal tools tailored to local workflows, those are substantial advantages.
The cost is a loss of uniformity. The publisher cannot assume that every instance has the latest code. Consumers must configure compatible resources, understand what the application expects, and decide whether to accept future changes. Support becomes more difficult because two people using the same Blueprint may have different bindings, data, edits, and versions. Security review also has to consider both the Blueprint’s design and the changes a consumer makes afterward.
The system’s own permissions reflect this distinction. A UI-only collaborator can use a deployed Gadget without automatically receiving the code-editing and connection-management surface available to a fuller collaborator. Conversely, publishing a Blueprint is a code-sharing act, not a way to grant a recipient access to the publisher’s connected resources. The application can be reusable without making the original authority reusable.
This is also where the SaaS comparison stops being sufficient. A SaaS document is easy to update centrally because one service controls the runtime. A Blueprint-based application is closer to a distributed collection of small software installations. That can be more personal and more adaptable, but it asks the people who create or adopt Gadgets to take ownership of lifecycle decisions that a SaaS provider would normally hide.
The next question is how this user-owned code can run at all without acquiring ambient network authority. The answer lies below the product lifecycle: a stateful Gadget runtime, a browser sandbox, and an explicit RPC path that allows the application to be useful while keeping its boundaries visible.