Moving a JavaScript application is straightforward until the application owns durable state. The code can travel in a repository. Its history, object identity, active connections, and recovery behavior need somewhere to go too.
That is the engineering question behind Cloudflare's October 9 announcement, "Deno is joining Cloudflare." Ryan Dahl and Kenton Varda describe an effort to bring celld and workerd together and improve self-hosting for Workers and Durable Objects. The announcement identifies a specific gap: workerd's existing Durable Objects implementation operates within a single instance. The planned work aims to make distributed operation practical outside Cloudflare.
This is a direction and an integration effort, not proof that every Workers application already has a complete migration path. Its significance is that the difficult part of portability has become an explicit engineering target.
A runtime can be portable while the application built around it still needs a platform to keep its promises.
The Runtime Is Only One Layer
workerd is the open-source JavaScript and WebAssembly runtime behind Workers. Its documented uses include hosting Workers applications, local development, and programmable HTTP proxies. It uses explicit capability bindings to connect code with resources and compatibility dates to preserve API behavior.
Those features make a runtime useful outside its original hosting service. They do not, by themselves, answer which machine owns an application object after a crash. Nor do they determine whether two machines can accidentally believe they own it at once.
A useful way to evaluate any portable platform is to separate four questions: can the code execute, can the data move, can the behavior survive failure, and can the operator maintain the result? A successful answer to the first question creates an opportunity. The other three determine whether it belongs in production.
Portability review
Execution Can the same application run?
State Can its durable data move intact?
Failure Does recovery preserve its guarantees?
Operations Can another team maintain the system?Object Identity Becomes Infrastructure
Durable Objects combine addressable compute with persistent storage. They provide a way to associate a unit of application state with a particular object, which is useful for coordination and applications with long-lived interactions.
Consider an original example: a collaborative inspection app in which each job has one object. A job contains findings, reviewer decisions, and a sequence of updates. Users connect to that job rather than choosing a machine. The application can organize work around a stable identity even while the infrastructure changes.
That is convenient precisely because the platform takes responsibility for facts the application would otherwise need to manage. A self-hosted implementation must decide where the object runs, route calls there, recover its data, and prevent competing owners from corrupting the job.
Adding machines is therefore a correctness change as well as a capacity change. A local program can make a decision from local state. A distributed service must also decide what it knows when communication is delayed or a host disappears.
The Useful Test Is A Failed Machine
A team's first evaluation should be deliberately small. Start with one application object, a sequence of writes, and a record of acknowledgements. Then interrupt the host at different moments and check what the recovering application can read.
The distinction between an accepted request and a durable result matters. If the caller saw success, which failure conditions can still remove that update? If the caller saw a timeout, can retrying create the same action twice? An application needs explicit answers before it can safely interpret an ambiguous response.
The same exercise should cover placement changes. Move an object while clients are connected. Restart a node during traffic. Interrupt communication between nodes. Verify that object identity remains stable and that any temporary unavailability is visible rather than silently converted into conflicting histories.
These are proposed evaluation criteria, not claims about bugs in celld or workerd. They are the evidence a new operator should seek from any system that takes responsibility for durable state.
Portability Includes A Restore Procedure
An open implementation is valuable because it allows inspection and adaptation. A practical exit path also requires a documented way to export data, preserve identities, rebuild configuration, and restore service somewhere else.
A backup that cannot be restored by a different team is a weak form of ownership. The same applies to a migration that works only while the original environment is available to explain missing settings.
For a pilot, keep an inventory of application bindings, object identifiers, data formats, secrets, and external dependencies. Preserve that inventory beside a restore procedure. Run the procedure into an isolated environment and verify application behavior against known records.
Count the manual steps. Every undocumented choice becomes a future incident dependency. Portability improves when those choices become repeatable operations with observable results.
Hosting Changes The Security Responsibility
workerd's README explicitly warns that the runtime alone is not a hardened sandbox for potentially malicious code. It recommends an appropriate additional boundary, such as a virtual machine. That warning matters for teams planning to run customer code or agent-generated applications.
A managed service packages more than language execution. An operator taking over the runtime also takes over patching, isolation, network access, resource limits, monitoring, and incident response. The architecture review should include those responsibilities from the beginning.
A sensible pilot can use trusted application code while the team learns the storage and recovery model. If the use case includes untrusted code, isolation needs its own design and verification. Making deployment easy does not make that work disappear.
A Better Question Than "Can We Run It?"
The promising part of the Deno and Cloudflare announcement is its focus on the distance between a runtime and an operable distributed application. That distance is where many portability claims become difficult to test.
Developers should watch for a coherent release, a documented support boundary, and reproducible recovery behavior. They should also ask whether an unfamiliar operator can restore a real application without relying on the original hosting service.
When those answers are concrete, self-hosting becomes a credible engineering choice. The application gets another place to run, and the team gets a clearer account of the infrastructure its code depends on.
// Discussion
Comments
No comments yet. Start the thread.