Why we built a server
for Ring.

Position · 2026-08-22 · Programming used to be: write the program, run the program. Somewhere along the way, running a backend became an evening of assembling other people's decisions. This is the case for putting it back — and the honest list of when you should not listen to us.

The evening you never get back

Count what a "simple" Node backend asks of you before your first endpoint answers: a runtime installed, a framework chosen (this year's), an ORM or a driver, a validation library, a config loader, a process manager — and a node_modules directory with a thousand strangers in it, any of whom can publish an update tonight. None of that is your application. All of it is your problem.

RingServ's opening move is to delete the evening: one downloaded file that already contains the web server, the language, the SQL database, the JavaScript engine and the validator. The supply-chain audit is reading one pinned list. The install instruction is a verb.

Five things you get that assembling does not give you

1 — Services, not routes. Every call is service.action(payload) at one endpoint, with one envelope back. No URL design meetings, no verb theology — and the wire shape is exactly what RingScript pages already speak, which makes fullstack symmetry free instead of a code generator.

2 — Validation the server enforces. Contracts are declarations, checked before your code runs, reporting every violation at once. Your actions never see a malformed payload — so they stop being half validation code.

3 — A record the law can rely on, built in. The journal is an append-only, fingerprint-sealed history with replay recovery and a verifier that exits non-zero for cron. Most stacks make you improvise this — money, audits, medical logs — out of a mutable table and good intentions. Here it is a first-class store, three declarations long.

4 — Offline as a declaration. Mark a table :local and the page keeps working without a network, syncing back exactly-once when it returns. The topology that places every piece is enforced by the server, not drawn on a whiteboard that drifts.

5 — Numbers instead of adjectives. A service round trip: 0.75 ms. A write: about a read. Peak: ~5,700 requests/s on four workers. And the losses are published with their causes, because a benchmark that only reports wins is marketing with axes.

Beside Ring's other backends

Ring already speaks server-side — WebLib under Apache, RingHttpLib's threads, and Youssef Saeed's elegant Bolt over a Rust engine. RingServ takes a fourth position rather than competing for theirs: it is not a routing layer but a whole application server — the unified model with RingScript, the built-in data and journal stores, the enforced topology, the zero-dependency operations story. The full survey of what we learned from each neighbour is in the landscape study.

When you should not use it

Honesty is the brand, so: if your team is fluent in Node and your stack already hums, keep it. If you need heavy numeric computing, a mature ORM ecosystem, or 1.0-frozen APIs today, we are not there yet — 0.9 means ready to use and still moving. And if you need the server itself to terminate TLS, we will keep saying no; the proxy in front is the design, not a gap.

The bigger bet

RingServ is one piece of the Softanza project's wager: that programming can be fun and simple again like the eighties, yet modern and powerful like 2026 — that a beginner's first backend and a professional's fiscal system can be the same tool held at different depths. RingScript made the browser feel that way. This is the server catching up.

Try the ninety seconds More articles