The Cratis Stack

The Cratis Stack

From a sticky note to a running, typed, full-stack app

Most stacks are a bag of libraries you bolt together and then spend the whole project keeping in sync. Developers choose Cratis because the layers are designed as one thing — a domain you model on Monday can become typed C#, authenticated tenant-aware requests, a live React screen, and an inspectable event log by Friday, with event sourcing as the default backbone for information systems and the handoffs handled by conventions, generation, and open runtime boundaries. Start building → · Why developers choose Cratis →

One idea, all the way down

Each product is strong on its own — you can use them separately. The reason to reach for the whole stack is that the seams disappear: CQRS shapes information going in and out, event sourcing keeps the facts underneath, and everywhere you’d normally hand-write glue, Cratis generates it.

• You model the domain, and Studio will generate the C# for it.
• You secure the edge, and AuthProxy authenticates, resolves the tenant, enriches identity, and routes requests.
• You write a command, and Arc generates the typed TypeScript proxy for it.
• You append an event, and Chronicle accepts it through a gRPC/protobuf boundary, stores it in MongoDB, PostgreSQL, Microsoft SQL Server, or SQLite, and projects the read model from it.
• You render a screen, and Components consumes the proxy with no API client to write.
• You run it, and the CLI, Workbench, OpenTelemetry, jobs, recommendations, and replay tools let you watch and operate the event store.

Nothing in that list is a thing you keep in sync. The build does.

Wiring the stack into one host is itself a single call: the Cratis package brings Arc and Chronicle up together with AddCratis/UseCratis, sharing storage, identity, and hosting.

Design, build, operate

The journey, end to end

Read it left to right: a domain idea becomes a secured tenant-aware request, a generated slice, a durable event, a live typed React screen, and an inspectable running system. AI can accelerate the same path because the conventions are explicit.

1. 01 Model / Studio Map the domain first Capture the command, event, read model, and team intent before the implementation spreads out. Open Studio
2. 02 Build / Arc Keep the slice together Put the command, handler, query, proxy, and UI for one behavior in one feature-shaped place. See vertical slices
3. 03 Secure / AuthProxy Resolve identity and tenant Authenticate once, resolve the tenant, enrich identity, and let services receive trusted context. Explore AuthProxy
4. 04 Record / Chronicle Store what happened Append facts through Chronicle's gRPC boundary and let projections turn them into read models on the storage backend you chose. Explore Chronicle
5. 05 Render / Components Ship a typed React screen Generated TypeScript proxies and Components remove the hand-written API client and form plumbing. Browse Components
6. 06 Operate / CLI + AI Inspect the running system Use the CLI, Workbench, and AI tooling to browse events, replay projections, and diagnose observers. Use AI tooling

Studio model Register author Command -> Event -> Read model

C# slice [Command] RegisterAuthor AuthorRegistered

Generated proxy RegisterAuthor.execute() AllAuthors.use()

fact projection live query

React screen Authors update live No API client to keep in sync.

operate $ cratis chronicle observers list $ cratis chronicle projections replay

AI

Secure and comply end to end

Authentication, authorization, tenancy, and compliance are separate concerns, but they travel through the same request. AuthProxy authenticates and resolves tenant context. Arc authorizes the command or query. The Arc + Chronicle integration writes events into the tenant’s Chronicle namespace. Chronicle encrypts PII by compliance subject, and Arc releases protected read models before serving query responses.

Auth and compliance end to end shows that flow across the stack: where identity is enriched, where access decisions happen, how subjects differ from event source ids, and what erasure requires after protected data has reached read models.

Test the same flow

The same column you draw in an event model is also the shape of the test:

That becomes a BDD-style specification:

Given	When	Then
no author exists for this id	RegisterAuthor runs through Arc	the command succeeds
no author exists for this id	RegisterAuthor runs through Arc	Chronicle records AuthorRegistered
AuthorRegistered exists	the read model projection handles it	the Authors screen can read the author

Cratis Specifications gives that shape a light wrapper over xUnit: Establish() is the given, Because() is the when, and each [Fact] is one then. Arc adds CommandScenario<TCommand> so the command runs through the real pipeline. Chronicle adds in-process scenarios for events, projections, and reactors. Together, you test the slice in the same language you designed it: facts in, command happens, facts and read models out.

Testing with Cratis walks through the packages and the full stack-slice example.

Build it with AI

Cratis ships first-class tooling so an AI agent can build and operate the stack alongside you. That works because the stack is intentionally conventional: the same feature shape, naming, generated boundary, Chronicle diagnostics, and CLI command catalog show up across products.

• cratis init drops the Cratis AI configuration into your repo — agents and skills (like new vertical slice and add projection) that already know the Cratis conventions, so an assistant scaffolds correct slices instead of guessing at the framework.
• The Chronicle MCP server lets an agent connect to a running store and inspect events, observers, and read models — the same window the CLI gives you, handed to your assistant.

Model in Studio, generate the slices, build them, inspect the result — an agent can take part at every step. AI-native development covers the setup and exactly what an agent can do.

Each layer, on its own and together

Studio — design

Model the domain on a collaborative event-modeling canvas and generate type-safe C# from it. (Coming soon.)

Chronicle — events

The event-sourcing engine: gRPC/protobuf boundary, .NET-first client, TypeScript and Elixir clients/contracts, MongoDB/PostgreSQL/SQL Server/SQLite storage, Orleans inside.

AuthProxy — edge

Authentication, tenant resolution, identity enrichment, routing, and invite-based onboarding in front of your services.

Auth and compliance — end to end

How authenticated tenant-aware requests become authorized operations, protected events, and released read models.

Arc — CQRS + proxies

Full-stack CQRS with generated, typed C# → TypeScript proxies. It pairs naturally with Chronicle, and can also run over MongoDB or EF Core.

Components — React

Command dialogs, forms, and live data tables that consume Arc’s proxies — a screen is a few lines.

CLI + Workbench — operate

Inspect and interact with a running store: events, observers, read models, recommendations, jobs, replay, failed partitions, and diagnostics.

Specifications — test

BDD-style specs over xUnit, with Arc command scenarios and Chronicle in-process event, read-model, and reactor scenarios.

Fundamentals — foundation

The shared .NET and TypeScript building blocks the rest of the stack is built on.

Where to start

Get started

Scaffold a project and watch one event flow through a projection and a reactor — in minutes.

Build a full-stack feature

Put Chronicle, Arc, and Components together — backend to React, type-safe throughout.

Test a full-stack slice

Turn an event-model column into given/when/then specs.

Choosing where to start

Greenfield or brownfield — pick an entry point and adopt one piece at a time.

Why developers choose Cratis

How the products stand alone and compose, and when the stack is — and isn’t — the right fit.