Chronicle

Chronicle

Event sourcing, the productive way

For information systems, this is the default architecture we recommend: store every meaningful change as an immutable event — the complete history of what happened — and turn those events into exactly the read models, reactions, and projections your application needs. Chronicle gives that event log a gRPC boundary, database-agnostic storage — MongoDB, PostgreSQL, Microsoft SQL Server, or SQLite — and tools you can actually operate. Get started → · Architecture →

Start here

Run Chronicle locally

Start the development image, wait for readiness, and clean it up.

Understand the architecture

Locate the protocol surfaces, kernel, runtime scopes, and persistent subscriptions.

Inspect with Workbench

Use the bundled local browser inspection and projection-preview boundary.

Run Chronicle locally

For the shortest local path, use latest-development. It bundles Chronicle and MongoDB and tracks the newest published development image. When repeatability matters, pin a released version in your application or deployment configuration rather than copying an image digest into a getting-started command.

1. Pull and start the current development image with Chronicle available only on this machine. MongoDB remains internal to the container.

   docker run --pull=always --rm -d --name chronicle \
     -p 127.0.0.1:35000:35000 \
     cratis/chronicle:latest-development

2. Wait for the local health endpoint to report readiness. The development image uses a self-signed certificate, so this command disables certificate verification only for this local check.

   curl --insecure --fail --retry 30 --retry-all-errors --retry-delay 1 \
     https://localhost:35000/health

   A successful response prints Healthy. At that point the kernel is ready for the next local evaluation step.

3. Stop and remove it when the evaluation is complete.

   docker rm -f chronicle

What this local start proves

A Healthy response proves that this local development container started. It does not establish production suitability, support, scale, security, durability, compatibility, a managed service, client/provider parity, or support for every topology.

Independent-use boundary

The self-hosted Chronicle kernel and bundled Workbench can be started without Arc or Components. Applications and clients still need compatible packages, protocols, and configuration for the Chronicle server they connect to.

Inspection surfaces

Chronicle Workbench provides a bundled local browser surface for authorized inspection of Chronicle runtime state and preview of supported projection behavior.

The Cratis CLI provides terminal workflows for inspecting and diagnosing Chronicle.

Inspection capability does not imply complete administration, production-ready mutation, client parity, federation, managed service, support, or an SLA.

Continue

Architecture

Understand the kernel, protocol, store, namespace, and subscription boundaries.

Workbench

Inspect Chronicle from the bundled local browser application.

Cratis CLI

Terminal inspection and diagnosis for Chronicle.

Chronicle source

Owning kernel, client, Workbench, and package source.