Skip to content

Cratis Templates

The Cratis Stack

Start your Cratis app with the conventions already in place

Every Cratis application follows the same conventions: vertical slices, model-bound commands and queries, events as facts, read models projected from the log. The Cratis templates give you a working application with those conventions already in place — a real project you can run in minutes, not a blank folder you fill in from documentation.

Install the templates once per machine, then follow Getting started to scaffold and run your first application:

Terminal window
dotnet new install Cratis.Templates

Cratis.Templates contains every template, including the Kotlin and Java versions of the full-stack application: dotnet new cratis --language Kotlin or --language Java selects them. The JVM templates are also published on their own as Cratis.Templates.Kotlin and Cratis.Templates.Java, and the Cratis CLI can scaffold every template with cratis new.

  • .NET templates. The template source references Cratis packages with a floating Version="*". When you scaffold, the post-creation actions add those packages at their current release and write the concrete version into the generated .csproj, so your project stays on the versions it was created with until you update them like any other package.
  • Kotlin and Java templates. build.gradle.kts requests the Arc Gradle plugin (io.cratis.arc) and the io.cratis:cratis dependency as latest.release. Gradle resolves them when it builds, and io.cratis:cratis brings the matching Chronicle client with it, so you do not choose the Arc and Chronicle pairing yourself. Gradle caches a dynamic version for up to 24 hours by default; ./gradlew build --refresh-dependencies picks up a release published since. For reproducible builds, replace latest.release with an exact version, or use Gradle dependency locking.
  • Frontend. package.json uses caret ranges. Commit the lockfile your package manager writes to record exactly what you installed.

What the application templates have in common

Section titled “What the application templates have in common”

The full-stack templates (cratis in C#, Kotlin, or Java, and cratis-aspire) share one shape:

  • Vertical slices. Each behavior is one slice: the command or query, the events it produces, and the React component that calls it through a generated TypeScript proxy. In the C# templates all of it shares one folder. In Kotlin and Java the backend slice lives under src/main/, its React components under SomeModule/, and the proxies under build/generated/arc-proxies/.
  • Model-bound by default. Commands and queries are plain records the framework maps to HTTP routes; there are no controllers to write.
  • Local infrastructure included. cratis ships a docker-compose.yml that starts the Chronicle development image (MongoDB bundled) and an Aspire dashboard. cratis-aspire starts Chronicle from its Aspire app host instead.
  • AI-ready. Every template, including the two Chronicle client templates, ships a .cratis/ai.json that selects its Cratis AI profiles, languages, and coding-agent harnesses. Run cratis ai update after dotnet new to install the guidance; cratis new does it for you. See Cratis AI in the CLI.
  • Builds clean. The .NET sample code compiles with zero warnings under the Cratis analyzers, so the first warning you see is your own.