ARC Deep Dive: From a URL to a Running Application

Open www.arcblock.io, and an application appears in the browser. How did that URL find the application, and where did its data come from? The screenshot below shows the result. We will unpack the visit in stages to see how ARC produces it.

English homepage captured on October 18, 2026.

Our website is one application served by ARC, the Agentic Realm Computer. The same runtime architecture can serve different applications under different domains. Each application has its own definition and resources. A person who signs in brings another part of the environment: an identity and access to personal data that can persist across applications.

In Beyond Serverless, I described why we are building a virtual computer on Cloudflare. Here I want to open that computer and follow a request through it. Where does Cloudflare hand control to ARC? How does a hostname become an application? When does personal data enter the picture, and what keeps another visitor from reading it?

The most useful image to keep in mind is a personal disk. An application supplies the software; the person brings access to their own workspace. Different applications can work with authorized views of that workspace. The disk stays with the person as the applications change.

Stage 1: From a domain to a Worker running ARC

The first part of the journey is familiar. DNS helps the browser find the service, TLS protects the connection, and Cloudflare accepts the HTTP request. A custom domain can point toward a service through a CNAME, with the corresponding hostname and certificate configuration. What matters for our story is that the request arrives carrying its original hostname.

Cloudflare’s routing configuration sends the request to a Worker running ARC. The platform hands over an HTTP request; ARC organizes page selection, caller context, and resource access from here.

Stage 2: Bring the ARC computing environment into readiness

The request has reached ARC’s entry point. How much of the environment must become ready depends on the work this visit requires.

ARC first considers the request’s identity information and checks whether a public page cache can answer it. An anonymous visit to a public article can return cached HTML without initializing the full host or attaching personal data. A request carrying credentials needs the corresponding caller check before ARC decides which pages it may reuse.

A cache miss continues to page routing. The implementation distinguishes two readiness points: getRouter() prepares the registry and domain router so page content can be found; getHost() waits for the full computing environment used by paths needing sessions, RPC, and related services. The page router can answer some public requests on its own, with the complete environment becoming ready as subsequent work requires it.

This is the virtual computer’s cloud startup phase. The runtime initializes AFS, connects host adapters, and prepares AOS services as needed. Cloudflare decides when to start a new execution instance; ARC reuses registries, applications, and services that are already ready. A browser visit may enter a newly starting environment or a computer that is already running.

ARC resolves configured full-host aliases or deployment domain rules to identify a Blocklet, then resolves its application instance. Brand domains such as our website use explicit domain associations; development environments can also configure subdomain rules beneath a chosen root. The Blocklet describes the software; the instance supplies the context of this installation. One software definition can serve different installations, with each hostname directing a visit to a particular destination.

That lookup is also an admission boundary. To make a domain open a particular application, the operator configures the relevant routing and application association. The runtime selects applications according to the deployment’s rules; a DNS pointer alone does not install a new Blocklet.

One ARC deployment can handle many bindings. Our official website, a community application, and another site can arrive through the same runtime entry point and resolve to different application instances. Cloudflare schedules execution; ARC selects the application and organizes the resource context needed to serve it.

A Worker instance can handle multiple requests, including concurrent requests, and another instance may handle a later visit. Cloudflare’s execution documentation explains that scheduling model. Application and personal-data boundaries must remain correct across it.

Stage 3: Load the Blocklet and mount instance data

After selecting a Blocklet, ARC organizes the resources needed to run it. Three mounts keep an important distinction explicit: the software itself, the data shared by this installation, and the current person’s data.

The same Blocklet can be installed with different instance configurations and data. One instance can serve several people, each with personal data of their own. Shared instance resources belong to the installation; the application’s interfaces and permissions determine what visitors can access publicly.

Application activation first attaches the software. The runtime interprets the Blocklet definition and makes its pages, scripts, and declared software resources available through the read-only /packages view. It can discover what content the application provides, how to present it, and which execution entries it exposes.

Installation data comes next. Two installations of the same software can have different settings and shared content; that operational data must also survive software updates. The runtime resolves the current instance’s data backend and attaches it at /instance. A Blocklet can supply initial content under /packages/seed/; the runtime attempts to copy missing files into /instance/ while retaining existing files. A version marker helps later startups determine whether to check the seed content again.

Together, software and instance resources form a base view that later requests can reuse. As a person enters, it attaches the caller-specific data view. The resulting filesystem expresses what software is running, which installation supplies its shared data, and who is using it now.

AFS, the Agentic File System, provides access to this tree. ARC can resolve a page, read its content, and produce a response from the application’s definitions.

The word “filesystem” is useful because paths provide a common way to address resources. Its implementation is broader than a directory on a local disk. An AFS Provider can expose resources backed by storage, a remote service, or another implementation. A caller works through the interface and permissions of the mounted resource rather than having to understand every underlying transport.

For the public article we started with, the immediate work may be straightforward: locate the article, read its content, render its AUP-defined presentation, and return the page. A different application can use the same general environment to read structured records or invoke a capability supplied through a Provider. The resulting response depends on the application and on what the caller is allowed to access.

AFS is the common foundation. Application software, operational data, personal resources and callable capabilities can all enter the same addressing and operation system. Mounts and projections organize them, applications use their own views, and Providers connect those views to different implementations. The interface builds on this foundation too, as we will see when the resources become a webpage.

This is the relationship among AFS, AOS, and ARC. AFS provides the resource interface. AOS, the Agentic Operating System, supplies operating-system behavior around sessions, identity, and access to those resources. ARC brings these pieces together as a virtual computer in a particular execution environment. Blocklets are applications inside that computer.

The separation lets us change how resources are delivered without asking every application to become a storage client. A mounted source may be local to the runtime, supplied by a deployed Blocklet, or reached through a remote AFS interface. HTTP is one transport for remote access. The remote endpoint still needs to provide the expected AFS operations, resource structure, and authorization behavior. A reachable web directory and a usable remote application source have different contracts.

This also gives application builders an extension point. A specialized backend can be represented by a Provider with a defined path surface and access rules. Its implementation can remain behind that boundary while the application works with it through AFS. The useful abstraction is a consistent way to reach capabilities, with each Provider retaining its own semantics and requirements.

The public visitor may now have all the resources needed for the final rendering stage. First, follow the other branch: an application that asks the visitor to sign in and needs access to personal data.

Stage 4: Attach the user workspace and build an isolated session view

Suppose the visitor opens a private document or saves a preference. ARC now needs to establish who is making the request. A hostname identifies the destination application. It says nothing about the person using it.

DID-based authentication gives that person a verifiable identity. The identity service verifies the login credentials carried by the request, and the runtime establishes the caller from that result. An arbitrary DID string supplied by the browser cannot select another person’s data mount. From there, authorization can bind actions and data access to that identity within the application’s context. This distinction is practical: the application has an identity, its installation has an identity, and the caller has an identity. Those roles must remain distinguishable throughout the request.

Software and installation data now have their places. The next attachment depends on the person: the runtime resolves that caller’s personal-data backend and selects the fragment for the current application instance. Existing personal data remains accessible through that fragment. The application’s own default-value and write logic handles any initial records or preferences.

ARC then supplies a caller-specific AFS view. The application’s common resources remain available, while the personal portion resolves according to the authenticated person and the relevant application instance. An anonymous visitor has no personal /user mount to browse. After authentication, /user can represent the current caller’s application-scoped data rather than a global directory shared with other visitors.

The Cloudflare runtime makes this separation explicit. /instance represents installation-scoped resources shared within that installation. /user is scoped using the caller’s DID and the instance DID. Access to a broader personal Space requires an explicitly configured user-scoped view, with restrictions on access across applications. The shape of the filesystem expresses who the resource belongs to and which context may use it.

Keeping identity outside an individual application also gives the personal environment continuity. A notes application and a community can refer to the same person, while their instance identities identify different destinations. DID gives data ownership and authorization a common reference that can remain recognizable when an interface changes.

That is why I like the disk analogy for Arc Space. When you use a different application, your accumulated work should remain connected to you. The application receives a view into the resources it has permission to use. A notes application might work with your notes; another application might work with selected records from that same personal environment.

There are several boundaries within this picture. Application-scoped user data, installation data, and access to the broader personal Space serve different purposes. They do not collapse into one unrestricted mount. Permission determines how much of the disk is visible, which operations are available, and under whose authority a write occurs.

The persistent data also lives beyond the Worker instance handling this request. In the Cloudflare implementation, structured records and storage metadata use D1-backed facilities, while object content can use R2. AFS Providers connect the path-level operations to their backing services. The Worker processes the operation; the storage service retains the result after that execution ends.

For example, Alice and Bob can both ask the same application to read /user/app/preferences.json. The application uses the same path, but each caller’s view selects a different user-data Provider and reaches that person’s preferences. When Alice enters another application instance, /user resolves to her fragment for that instance. One personal Space supports the relationship, with a corresponding view for each application.

Think of separate application directories on the same disk. A new application opens its own directory by default; existing documents remain where they were. Continuing work on a particular old record requires explicitly providing it to the new application, for example by importing it into that application’s data fragment. Shared resources likewise need an explicit interface and authorization. The person retains the data, and the application receives a specific access scope.

Consider saving a document. The application addresses an allowed resource through the caller’s AFS view. The runtime applies the identity and access context; the backing Provider performs the storage operation. A later request can reach the saved result through a fresh execution instance because the document’s identity and storage scope never depended on the memory of the earlier Worker.

This is the important separation: the application defines the work, the runtime executes it, and the person’s persistent context has its own identity and access boundaries. Replacing an execution instance is routine infrastructure behavior. Replacing an application should become easier when the personal records it works with remain independently addressable.

Alice, Bob and Tom on the same website

Many people using one service can evoke the old shared-hosting picture: everyone enters the same machine. Could one visitor follow their own entry point into another person’s files? Could an application operation turn into control over the host? Those are precisely the boundaries the architecture must define.

Alice, Bob and Tom can see the same website in their address bars. ARC builds a caller-specific, session-specific resource view for each of them. In the computing model, each person enters a separate logical environment: their identity selects their personal /user mount, the session carries its own resource and access context, and permissions constrain the available operations.

A session-specific AFS overlay makes this concrete. It attaches the caller’s resources over a reusable application base without adding Alice’s personal mount to a base object shared by everyone. Bob’s session has no /users entry through which to enumerate all callers’ directories. His /user resolves to his own application data. Persistent storage uses scopes derived from the caller and application instance, carrying the boundary through to the actual read or write.

This is also an expression of AFS’s Small World design. An application receives its resource world, and the session overlays the current caller’s personal view. It receives a local namespace for its work; the rest of the system does not appear in that tree by default. Limited disclosure starts with the visible paths. Bob’s view attaches Bob’s personal data without offering an entry for browsing every user’s space. Within the view, access modes and operation permissions determine how those resources may be used. Narrowing what is visible and restricting what can be done work together, bringing isolation into the AFS layer.

The three boxes represent separate logical session environments. Beneath them, Cloudflare uses V8 isolates to separate execution environments and schedules requests; ARC builds session views and data-access boundaries above that foundation. One Worker isolate can process requests from several sessions. Requests may also run on different execution instances or in different locations. Tying the boundary to identity, session and resource scope lets it hold across those scheduling choices. Cloudflare’s execution model and ARC’s session model have complementary responsibilities here.

People can still exchange data. Alice might publish a community post, which Bob reads through an interface the community application provides. The application defines which resources are shared and which operations are allowed; Bob continues to use his own session view. Reading a shared post requires access to that content, while the author’s personal workspace keeps its own boundary.

Permissions continue along the operation. An application sees the resource interfaces mounted for it and can perform the operations its declarations and authorization permit. An ordinary application request does not acquire administrative authority over the host. Cloudflare’s execution boundary, ARC’s session resource views, and the Provider’s handling of actual access work together to limit lateral access from one caller’s entry point to another caller’s resources.

DID matters because the system needs a stable, verifiable answer to “who is acting?” It gives authentication and authorization a common identity reference. TLS protects the network connection; permissions determine which resources and operations a caller can use. These mechanisms have separate jobs.

The hosted runtime is also part of the trust boundary. When a service processes an authorized document operation, its implementation must handle that data correctly. Security depends on credential verification, correct permission enforcement, scoped access, and the underlying infrastructure. An identity identifier cannot substitute for any of those controls.

Stage 5: Turn the resources into an application in the browser

Return to the homepage screenshot at the start. A public visit can arrive here through the cache or page-router branch. An application needing personal data first prepares the corresponding caller view.

AFS-UI is the interface system built on AFS: interface structure, related state and supported operations can also enter its addressable resource space. AUP, the Agentic UI Protocol, provides conventions for describing interface structure and interaction. Resource access and presentation can connect around the same objects. People use the visual interface; agents can inspect and operate through supported paths.

This example follows the Web Device website presentation pipeline. The runtime finds the page definition and reads content available in the current view. The Web presentation pipeline produces HTML from the layout and content, then delivers it with styles, scripts and images. The browser parses and paints those resources. The URL becomes a website a person can read and use: navigation, article cards and links are the visible result of this chain.

AFS-UI can also reach beyond webpages. The Swift and Kotlin implementations include native interface renderers that turn supported descriptions into native controls. Each implementation determines which elements and interactions its device supports. Our homepage journey ends in a browser; the resource and operation model also provides a foundation for other device interfaces.

Inside a live interface session, AUP describes the interface and its interactions. An action can re-enter the session’s execution context, read an authorized resource, update state, and produce the next view. On Cloudflare, Durable Objects provide a useful coordination primitive for stateful sessions. Their identity and coordination model are described in Cloudflare’s documentation.

The session can maintain interaction continuity while personal records remain in persistent storage. A browser button, a UI update, and a data write are connected operations, but they have different lifetimes. Making those lifetimes explicit is part of building a virtual computer on an infrastructure designed to schedule and replace execution instances freely.

The computer can have different homes

Follow the request back out and the result looks simple again: the browser displays a page, and a document remains available when its owner returns. Behind that result, Cloudflare accepted and scheduled the request; ARC selected the application, established the caller’s view, and coordinated access to its resources.

Different hosting requirements can build on this division of responsibility. Shared hosting puts many registered applications behind a managed ARC deployment. Dedicated operation gives an organization a separately managed runtime and resource configuration. Self-managed operation places that responsibility with the operator. Each choice still needs explicit domain bindings, storage configuration, and identity boundaries.

Cloudflare has relevant building blocks for those choices. Cloudflare for SaaS addresses customer hostname onboarding and delivery. Workers for Platforms provides user Workers and dynamic dispatch for platforms hosting executable workloads. The architectural decision is which boundary a deployment needs: a customer domain, a dedicated application environment, or separately dispatched code. Integration and operation follow from that decision.

The virtual computer model also reaches beyond Cloudflare. ARC has a Node runtime for conventional computing environments and native implementations in Swift and Kotlin. A Linux server, a container, and a mobile device offer different resources and execution conditions. Their Providers determine what appears in AFS and what the computer can do. A device deployment needs an appropriate runtime implementation and a realistic resource surface for that device.

Cloudflare is a particularly useful home for our hosted implementation because its execution, coordination, and storage services can support the different parts of this computer. ARC supplies the layer that connects them to applications and people.

That is what happens behind the URL. The domain opens an application; the application runs inside a virtual computer; the person brings an identity and authorized access to their own persistent workspace. The page may be temporary. The Worker instance may change. The important continuity is the person’s ability to return to their data, grant access to another application, and keep working.