Question 1

Why not just use a transaction and a row lock?

Accepted Answer

Often you should. If the whole job is read a row, decide, write it back, and answer the request, then a transaction with SELECT ... FOR UPDATE does that and you need nothing else installed. In the browser, navigator.locks is the same answer. The ticket sale in the quickstart is different because of one line: the hold expires in ten minutes. No transaction stays open for ten minutes, so a lock cannot cover the expiry. A setTimeout does not cover it either, because it dies when the process restarts. You end up putting an expiresAt column on the row and writing a sweeper to find expired holds, and now two things touch that row on different schedules. If all the work happens inside one request, use a lock. Install this when work must happen later, or must survive a restart.

Question 2

Isn't this one UPDATE statement?

Accepted Answer

For a plain counter, yes, and you should use the one statement. UPDATE ... SET remaining = remaining - 1 WHERE remaining > 0 will not oversell and needs nothing installed. The ticket sale in the quickstart needs three behaviors from the same number. The count must never go below zero. The seat must return if the buyer does not pay within ten minutes. Every open page must show the current count. Written by hand, the first needs one statement, the second needs a column and a sweeper, and the third needs a push on every path that changes the number. These three must agree with each other.

Question 3

Why not broadcast over my own WebSocket after the write?

Accepted Answer

For a like count or a dashboard number, do exactly that. Write, then send on the socket. That needs less code than this library, and it is sufficient for that case. Two problems occur when several people write to the same record at once. First, each request builds its payload in its own process and sends it. The lock sets the write order, but it does not set the order in which the two sends arrive, so a viewer can keep the older one. Second, the send is not part of the write. If the process stops after the database commits and before the send goes out, the tab shows the wrong number, and nothing corrects it. observable in the quickstart example prevents both problems. The value publishes from the same turn that saved the change: the publication commits with the state, a worker delivers it in revision order, and subscribers reject a stale revision, so a viewer cannot end up on an older number.

Question 4

Can I run Durable Objects without Cloudflare?

Accepted Answer

Yes. Solid Objects is an open-source MIT library that runs the Durable Objects programming model inside your own Node.js application, with state in SQLite, PostgreSQL, or MySQL. celld, from Deno Land, is another option: a self-hosted daemon that runs Workers code on your own VMs with state replicated to an object-storage bucket.

Question 5

How is Solid Objects different from celld?

Accepted Answer

celld is a self-hosted daemon: you operate celld nodes on VMs plus an object-storage bucket, and each cell is its own SQLite database replicated to that bucket. Solid Objects is a library: it runs inside the app you already deploy and stores state as tables in the SQL database you already run. Neither requires Cloudflare. Choose celld for the full Workers API on your own fleet; choose Solid Objects for durable actors in one app with no new infrastructure.

Question 6

Can I use Solid Objects in the browser or a frontend app?

Accepted Answer

Yes, in two ways. The full runtime runs inside a browser module worker: actors look exactly like they do in Node, the database is SQLite WASM, and durable state lives in OPFS, so it survives page reloads. Multiple tabs share one database through Web Locks leader election and a BroadcastChannel, with failover onto the same durable state, and solid-objects/transmit reconciles offline writes to a server runtime with at-least-once delivery and idempotent ingest. Separately, solid-objects/browser is a zero-Node-imports realtime client for subscribing to server-side actors, with reconnection, replay, and revision fencing over the native WebSocket.

Question 7

Can I use the JS library in the frontend with a Rails backend?

Accepted Answer

Yes, that pairing is a designed use. Run the solid-objects browser runtime (or the subscriber client) in the frontend and the solid_objects Ruby gem in Rails. Since the 0.14 releases the two implementations share the transmit wire contract: a browser actor stages writes in the same transaction as its state change, drains them with at-least-once delivery and per-actor order, and Rails ingests each envelope idempotently through SolidObjects::Transmission.receive at POST /solid_objects/transmit, behind a deny-by-default authorization policy. Browser-to-Rails, Node-to-Rails, Rails-to-Node, and Rails-to-Rails all ride the same contract, pinned by golden fixtures committed to both repositories.

Question 8

Is Solid Objects affiliated with Cloudflare?

Accepted Answer

No. Solid Objects is an independent open-source project that ports the Durable Objects programming model to Node.js. It does not reproduce Cloudflare's edge placement, global routing, WebSocket hibernation, or storage APIs.

Question 9

Does Solid Objects guarantee exactly-once execution?

Accepted Answer

No. Delivery is ordered per identity and at least once. Operations and external effects can repeat, so external effects must be idempotent and deduplicate by their stable effect id. Fencing ensures at most one valid activation lease holder can commit.

Question 10

Do I need Redis or a message broker?

Accepted Answer

No. State, mailbox, leases, fencing, retries, timers, and outboxes live in SQLite, PostgreSQL, or MySQL. Redis is an optional wake-up latency layer; losing it increases polling latency without losing committed work.

Question 11

Is Solid Objects for Node.js production ready?

Accepted Answer

It is an early pre-1.0 release (v0.14.8). There is one deployed first-party reference application. There is no measured scale and no third-party production use yet. Evaluate it with the runnable quickstart, the reference application, and the repository test suite.

Question 12

Which Node.js and database versions are required?

Accepted Answer

Node.js 24.4 or newer and TypeScript 5.9 or newer. SQLite uses Node's built-in node:sqlite. PostgreSQL 14 or newer uses the optional pg driver. MySQL 8.0 or newer with InnoDB uses the optional mysql2 driver.

	Solid Objects A library in your app	Cloudflare Durable Objects A managed platform	celld A daemon on your VMs	SQL transaction Already in your database
Runs with no new service	Yes A Redis wake-up is optional	No The Cloudflare platform	No A daemon on every node	Yes
State lives in the database you already run	Yes SQLite, PostgreSQL, or MySQL	No Managed storage for each object	No One SQLite file for each object, in your bucket	Yes
One call at a time for each identity	Yes	Yes	Yes	No Only inside one transaction
Work continues after a restart	Yes	Yes	Yes	No The transaction rolls back
Timers that survive a deploy	Yes Reminders are rows	Yes Alarms	Yes Alarms	No A column and a sweeper
Side effects commit with the state	Yes A staged outbox	No You write it	No You write it	No
Realtime updates to open pages	Yes Committed projections	Yes WebSockets	Yes WebSockets	No
One transaction across two identities	No	No	No	Yes In the same database
Runs with no vendor account	Yes	No	Yes	Yes

Durable Objects on the SQL database you already run

How this compares