Larry Maccherone

Cloudflare's Durable Object Facets shipped on April 13, 2026[^beta]. Cloudflare's framing is that they're "essentially free." That's accurate at the infrastructure layer — same V8 isolate as the parent DO, no extra billing line, no separate Worker. However, from the cold-wake and per-call latency perspectives, it's not zero, and I needed to know by how much.

While building Nebula, I wanted to host a per-tenant typia parse-validator close to each tenant's write DO. Facets were the obvious choice, but I wanted real numbers before committing. This post is what I measured: cold-wake contribution and warm RPC boundary cost. For the non-facets-related benchmarking results — throughput, gate semantics, and what I had to unlearn about Durable Objects under load — see the companion post: What I got wrong about Durable Object throughput.

@lumenize/ts-runtime-parser-validator is shipping. Your TypeScript interfaces are the runtime validation schema — no Zod, no JSON Schema, no DSL. Powered by typia and hosted as a Cloudflare Durable Object facet: ~16 ms warm end-to-end through a DO + facet SQL transaction (storage-write output gate latency included) and ~400 transactions per second in a single DO instance under heavy concurrent load, with @default filling, cycle and alias support, and per-tenant hot-swap of the schema at runtime. This post is the announcement; for the performance breakdowns, see Cloudflare DO Facets in practice (cold-wake, boundary cost, when-to-use) and What I got wrong about DO throughput (the gate-semantics surprise).

I've spent four+ years building on Cloudflare Durable Objects. The mental model I leaned hard into — input gates make your code passively correct as long as you don't await across critical sections — works beautifully for simple workloads, and it served me well for years. As I started building Nebula, a moderately complex distributed system, that model was insufficient. This post is what I learned benching that system end-to-end: real numbers from a real workload (not a microbenchmark), and how I had to expand my mental model beyond input gates = correctness.

Cloudflare recently opened the beta for Email Sending. @lumenize/auth has switched its default email transport to use it.

You've been writing the same types four times.

Once as a TypeScript interface. Once as a Zod schema for validation (or the other way around — Zod's z.infer can derive the type, but you're still writing Zod's DSL). Once as a Prisma model for your ORM. Once as SQL for your database. Multiple representations of the same thing, each in a different language.

Here's what that looks like for a simple Todo with an assignedTo relationship:

Cloudflare's Code Mode team made a striking discovery: when they converted JSON Schema to TypeScript for MCP tool definitions, LLMs performed dramatically better. The follow-up showed 32-81% token reduction with improved accuracy. And today, their Dynamic Workers platform doubles down — TypeScript interfaces are the way agents understand APIs. As they put it: "Agents know TypeScript... with very few tokens, you can give your agent a precise understanding of your API."

That got me thinking. If TypeScript is the best way to describe types — for both humans and LLMs — why are we still maintaining parallel schemas in Zod or JSON Schema to validate them? You already write TypeScript interfaces. What if those interfaces were the runtime validation schema?

Cloudflare Durable Objects with SQLite storage charge $1.00 per million rows written and $0.001 per million rows read. Writes are 1,000x more expensive than reads. The docs tell you that "every row update of an index counts as an additional row written" — but that's where the guidance ends.

How much does a compound index cost? Does WITHOUT ROWID actually save money? If I update a column that isn't indexed, do I still pay for the indexes? Does UNIQUE have an impact? Questions like these come up regularly on the #durable-objects Discord, and I've never seen an experimentally-validated publication that answers them. So I wrote 36 tests and measured everything.

If you're building on Cloudflare Workers and Durable Objects, you've probably wired up auth at least once — JWT validation, token refresh, key rotation, permission checking. It's not glamorous work, and bolting on an external auth service (Auth0, Clerk, Supabase Auth) means another dependency, another bill, another point of failure, and latency from round-trips to someone else's infrastructure.

@lumenize/auth is a different approach: passwordless authentication that runs entirely inside your Cloudflare Worker. No external service. No SDK. Just a Durable Object that handles magic-link login, JWT signing, refresh token rotation, and access control — all at the edge.

Today we're releasing Lumenize Mesh in beta — a de✨light✨fully radical new way to build on Cloudflare Workers and Durable Objects, where DOs, Workers, and browser clients are all equal peers in one mesh.

Lumenize Nebula is an agentic software engineering platform built on Lumenize Mesh. Define your business ontology declaratively. Nebula handles the rest.