The stack

Designed as one thing.

Most stacks are a bag of libraries you bolt together and then spend the project keeping in sync. The point of Cratis isn't that there are many packages — it's that the packages agree about how an application is shaped.

One feature, every layer

Follow one behaviour all the way through.

This is where the difference shows. Not in a feature list — in what happens to a single piece of behaviour as it crosses every boundary in your system.

01 Model

Map the domain

Capture the command, the event, the read model and the team's intent before the implementation spreads out.

Studio

02 Build

Keep the slice together

Command, handler, query, proxy and UI for one behaviour, in one feature-shaped place.

Arc

03 Record

Store what happened

Append facts through the gRPC boundary and let projections turn them into read models.

Chronicle

04 Render

Ship a typed screen

Generated TypeScript proxies remove the hand-written API client and the form plumbing.

Components

05 Operate

Inspect the running system

Browse events, replay projections, diagnose observers — from the terminal or an agent.

CLI · MCP

Nothing in that sequence is a handoff you maintain. The build maintains it.

The pieces

What each one owns.

Chroniclethe event store

Records what happened, in order, immutably — and derives read models from it. Projections, reducers and reactors turn the log into the state your screens need. Constraints are enforced server-side at append time, so invalid facts never enter the record.

  • gRPC / protobuf boundary
  • MongoDB
  • PostgreSQL
  • SQL Server
  • SQLite
  • Orleans runtime
  • Replay & recovery
  • Namespaces for tenancy
Chronicle documentation →
Arcthe full-stack CQRS framework

Turns behaviour into a typed application. A C# command becomes an HTTP endpoint and a generated TypeScript proxy — so the frontend can't drift from the backend without the compiler saying so. Identity, authorization and tenancy are part of the framework, not per-app boilerplate.

  • Commands & queries
  • Proxy generation
  • Roslyn analyzers
  • Tenancy
  • Identity & authorization
  • Works without event sourcing
Arc documentation →
Studiothe modelling surface · commercial

Where the domain is designed — commands, events and read models on a shared canvas, with the whole team in the room. The point is not a better diagram; it is changing who can take part in designing the software. Screenplay writes that model down as a single declarative file, and Stage performs it: a live application, interpreted at runtime rather than generated. Prologue brings an existing system in by capturing what it already does.

Studio is the one commercial product in the stack — in beta now, priced in public at cratis.studio. Everything else on this page is MIT, including everything you deploy.

  • Event modelling canvas
  • Screenplay .play
  • Stage runtime
  • Prologue capture
Studio →
Componentsthe React library

Renders Arc's generated proxies as forms, dialogs and data tables. A screen becomes a few lines rather than a few files, and observable queries keep it current without reload code.

  • Command dialogs
  • Data tables
  • Schema editors
  • Observable queries
Components documentation →
AuthProxythe edge gateway

Authenticates once at the edge, resolves the tenant, enriches identity, and forwards trusted context to your services — in front of any backend you point it at.

  • Authentication
  • Tenant resolution
  • Identity enrichment
  • Routing & invites
AuthProxy documentation →
The toolsthe operating surface

A terminal window into a running store, a VS Code reader for the event log, a browser extension for stepping into another user or tenant, and an MCP server that lets an assistant do the same in plain language. Inspect-only by design — to change state you still go through commands and events.

  • CLI
  • Narrator
  • Lens
  • Synopsis
  • Chronicle MCP
  • Prompter
Meet the cast →

Adoption

Take one piece, or take all of it.

Each product solves a complete problem on its own. The dependency only runs one way — Arc can sit on top of Chronicle, but Chronicle never knows Arc exists.

Which Cratis products to reach for
You want Reach for Event sourcing?
History as the source of truth, from any runtime Chronicle on its own Yes
A typed full-stack app over a traditional database Arc + Components over MongoDB or EF Core Not required
Authentication, tenancy and routing at the edge AuthProxy in front of your services Optional
A typed full-stack app and a full event history Arc + Chronicle + Components Yes
A product-grade SaaS shape, end to end AuthProxy + Arc + Components + Chronicle + CLI Default

The last row is where the stack is at its best, and it's the default for a new information system. Coming from an existing one? Adopting Cratis walks through taking one piece at a time.

Open

No boundary you can't cross

MIT licensed. Chronicle speaks gRPC and protobuf, with .NET, TypeScript, Kotlin and Elixir clients. Storage is a deployment choice, not an architecture decision. Nothing here is a door that only opens inward.

Opinionated

On purpose, and only where it pays

Conventions over configuration, vertical slices over layers, facts over current state. The opinions are what make codebases consistent — and consistency is what makes onboarding fast and AI assistance less speculative.