Show me the exit

Cloudflare's joint announcement with Dahl acknowledges that workerd, their open runtime, supports Durable Objects on a single instance but has lacked the surrounding ecosystem for scalable self-hosted production. Their plan is to bring celld's distributed-system work into workerd and make self-hosting a first-class option.

Publishing the code that executes an application does not automatically publish everything required to place it, route requests to it, and recover its state when a machine disappears. The integration remains a plan.

Durable Objects combine addressed instances of compute with private, transactional storage. That can give an application a convenient place to coordinate work. It also makes the behavior of that place part of the application: what identifies an object, where its data lives, and what happens when two requests arrive together.

Changing hosts leaves those dependencies in place even when the JavaScript looks unchanged. A deployment that serves the homepage tells you little about a payment arriving during a restart.

The workerd README warns that it is not a hardened sandbox, and recommends additional isolation when running potentially malicious code. That warning concerns untrusted workloads; it does not rule out running trusted applications.

The joint announcement describes customers who have migrated away using workerd, and celld offers a self-hosted, distributed implementation of Durable Objects.

A small team can reasonably buy managed operations because operating a distributed system would distract it from serving customers. A platform can also provide behavior that would be difficult to recreate with generic components.

The team should understand which responsibilities it bought and which it would take over by leaving. The mistake is leaving migration work out of the decision because the runtime has an open license.

A business may accept a maintenance window that another cannot tolerate, or decide that an expensive migration is preferable to ongoing infrastructure work.

Follow a hypothetical migration of an invoice service. The service receives a payment webhook, records the event as processed, marks an invoice paid, and arranges for a receipt email. A scheduled task checks for unfinished receipts, and customers can sign in to see their invoices.

The team ports the handlers and successfully opens the invoice page on the new host. It restores invoice records from a backup, but overlooks the processed-event records. A repeated payment notification arrives. The new service sees an already-paid invoice, yet its event handling code has lost the record that this notification was processed. Depending on the design, it might enqueue another receipt or apply another side effect.

Processed-event records belong in the restore alongside invoices and customer accounts. When an abstraction changes, the team must also decide how its old identifiers map to the new system.

celld's compatibility reference lists supported APIs and configuration, and points to operational limits. Check the service's dependencies against that support and its documented gaps.

Workers' Node.js compatibility documentation distinguishes functioning APIs from import-only stubs, including child-process functionality. If the invoice service generates receipts through a subprocess, compilation alone would be a poor test. The team needs to exercise receipt generation, or deliberately replace it.

Deno KV's backup documentation describes continuous backups to an owned S3-compatible bucket and points to denokv for using them.

For the invoice service, begin in a clean test environment with synthetic records and test credentials. Restore from the documented artifacts, then verify a customer can see their own invoices and cannot see another customer's. Check an already-processed payment event, an unfinished receipt, and a payment arriving after the restore point.

Keep outbound email isolated during rehearsal. A replay intended to verify recovery should not accidentally send real receipts. Retain a trace connecting each input event to its persisted state and intended side effects, so a successful response does not conceal missing work.

Account for writes accepted between the backup and cutover, including how they will reach the new host. A plan might pause writes briefly to capture a final change set. For the invoice service, identify which host accepts each payment event during the move.

Write down when the old service stops accepting work and when the new service starts. Also account for scheduled jobs and delayed notifications; changing a public route does not automatically transfer every source of activity. If both hosts can process the same payment, the plan must explain how duplicate delivery is handled.

Test rollback with writes made on the new host. Suppose the new service accepts payments before a defect forces a rollback. Sending traffic back to the old host does not place those new writes there. The old database might be healthy and incomplete. Before changing the route, document how rollback will handle writes accepted on the new host. The plan needs a way to reconcile them, or a boundary beyond which returning requires a different recovery procedure.

Leave a record of the rehearsal that another engineer can inspect: restored records, event traces, unresolved failures, and the steps taken. Compare the observed recovery with the interruption and data-loss limits the business can accept. A rehearsal with synthetic data can expose a missing dependency; production scale remains a separate test.

Give a candidate a small, synthetic invoice service with a documented old host, a proposed destination, and a few test payment events. Ask them to identify what must survive and demonstrate one recovery property. Start with a repeated payment notification, then ask what evidence they would need before accepting writes on the replacement.

Give the candidate documentation for both hosts and explain how their recovery reasoning will be evaluated. Keep the task confined to the synthetic service; it should not become unpaid migration work or a test of obscure vendor terminology. Evaluate whether the candidate notices the lost processing history and can explain how to protect it. This is a proposed exercise, not a validated claim about predicting job performance.

For a team leaving Deno Deploy, the remaining rehearsal failures and the work needed to resolve them should inform the destination choice while the old service is still operating.