Why Cratis
The honest version.
You're comparing options. Here's where we're genuinely different, where we're not, and when you should pick something else.
What changes day to day
Instead of… you work with…
| Instead of | You work with |
|---|---|
| Duplicating request and response shapes in C# and TypeScript | One C# command or query model, generated into typed frontend proxies |
| Spreading one feature across controllers, handlers, clients and UI folders | A vertical slice organised by behaviour |
| Rebuilding screens by hand after a write | Observable queries and components that follow the read model |
| Rebuilding authentication, tenancy and identity plumbing per service | AuthProxy at the edge, Arc identity and tenancy inside, Chronicle namespaces underneath |
| Teaching every developer and assistant a project-specific architecture |
Strong conventions, analyzers and .ai guidance
that make each feature look like the rest
|
| Locking event history to one language or database engine | An open gRPC boundary, four client languages, four storage backends |
| Debugging from logs alone | Events, observers, read models and replay, visible through the CLI and Workbench |
The four things we'd defend
What we actually claim.
One model, end to end
The point isn't that Cratis has many packages. It's that the packages agree about how an application is shaped. A command, an event, a read model, a tenant, an identity, a React form and an operating tool are parts of one model — not islands with separate conventions.
A history you can question
Event sourcing optimises for understanding change, not storing the latest value. Events are facts: immutable, past-tense, single-purpose. Read models are disposable, because the events are the state.
Rails an agent can follow
Analyzers that fail the build on convention drift, skills that teach assistants the conventions, and an MCP server that makes the running store legible. A convention you can break silently isn't a convention — it's a suggestion.
Open at every boundary
Everything you deploy is MIT licensed. gRPC and protobuf at the Chronicle boundary. Storage is a deployment choice. The pieces stand alone — Chronicle without Arc, Arc without event sourcing. The dependency only runs one way.
Coming from libraries
If you're using Marten and Wolverine.
Let's start with the part that isn't a sales pitch.
Marten is excellent. Eleven years of production use, millions of downloads, and a reputation it earned the hard way. Jeremy Miller has been doing this longer than we have, and the Critter Stack is a genuinely good answer to the problem it set out to solve.
If you're backend-only, committed to PostgreSQL, and you don't have a frontend contract problem or a modelling gap — stay where you are. You'd be trading a mature, well-supported library for a younger one to solve a problem you don't have.
Maturity and reach
More years in production, a larger community, more people who have already hit your problem and written about it. If that matters more than anything below, it's a good reason to choose them.
Scope, not quality
They give you an event store and messaging. We carry the frontend contract, the edge, identity and tenancy, and a modelling surface as part of the same set of conventions. That's a different bet, not a better library.
Teams come to us when the gaps they're feeling are the ones between the layers — the hand-written API client, the DTOs mirrored in two languages, the design that lives in someone's head. That's the part we built.
Coming from an enterprise platform
If you're looking at a JVM event platform.
Different runtime, different buying motion, and one real architectural difference.
| Enterprise JVM platform | Cratis | |
|---|---|---|
| Runtime | Java | .NET, with TypeScript, Kotlin and Elixir clients |
| Storage | Their server | MongoDB, PostgreSQL, SQL Server or SQLite |
| Licence | Commercial licence for production | MIT for everything you deploy; Studio is a paid design-time product |
| Frontend | Not addressed | Typed C# → TypeScript → React |
| Model to system | An agent generates code from the model | Stage runs the model |
| Buying | Sales-led | Public pricing, self-serve |
| Getting help | A support portal | The person who wrote it |
Where we won't compete: they have fifteen years, regulated-industry deployments, and a scale record we don't have an equivalent for. If your evaluation weights those most heavily, that's a legitimate reason to choose them. We compete on shape and on access.
The part most sites leave out
When Cratis is the wrong choice.
Because the products are separable, "is Cratis a good fit?" is really several questions.
You're not on .NET
Chronicle's boundary is open and there are clients for TypeScript, Kotlin and Elixir — but .NET is the first-class experience and we're not going to pretend otherwise.
Your slice is genuinely current-state-only
Reference data, settings, a small admin surface. Event sourcing is pure cost there. Arc over MongoDB or EF Core is the simpler boundary, and it's a first-class path.
It's a prototype you'll throw away
The conventions pay off over years. If the code won't live that long, they're overhead.
You want the largest possible community
We're younger and smaller than the alternatives. If "someone has already written a blog post about my exact problem" is your top criterion, weigh that honestly.
When none of it fits — a couple of static pages, a non-.NET backend, or a throwaway prototype — Cratis is more than you need, and that's fine.