Deployments Overview

Causet separates authoring from running. You write .causet files locally, compile them to verified IR artifacts, package them as a release, and deploy that release to a fork — an isolated runtime environment for your application.

Every intent, query, and projection handler resolves against the active release on the fork you target.

The deploy pipeline

Step	What happens
Compile	`causet build compile` validates cross-references and emits IR into `dist/`
Release	`causet release create` + `causet release publish` — immutable tagged snapshot
Deploy	`causet deploy apply` + `causet deploy activate` — live rules on a fork

Core concepts

Concept	One-line definition
Fork	Isolated environment (schema + active release) — e.g. `main`, `staging`, `test-abc123`
Release	Immutable compiled IR snapshot created from uploaded artifacts
Deployment	The act of activating a release on a fork

Why forks matter

Every API call includes a fork:

{
  "forkId": "main",
  "action": "CHECK_IN_TO_SHOW",
  "entityId": "user-1",
  "payload": { ... }
}

The runtime loads entity state, rules, and event handlers from the active release on that fork. The query service loads SQL templates from the same release. The projection worker applies DDL and handlers for that fork’s PostgreSQL schema.

Two forks on the same application can run different releases at the same time — staging on yesterday’s build while production stays on the current release.

Tenant isolation per fork

Each fork gets its own PostgreSQL schema for projections:

{platformId}_{applicationId}_{forkId}

Example: platform acme, application concert-app, fork main:

acme_concert_app_main

Ledger events and entity snapshots are also scoped by fork. Data never leaks between forks.

Typical workflow

causet build compile  --runtime ./concert-app/ --out dist/
causet release create  --input dist/ --tag 1.0.0
causet release publish --tag 1.0.0
causet deploy apply    --tag 1.0.0 --fork staging
causet deploy activate --tag 1.0.0 --fork staging --mode FULL
# test, then repeat apply + activate for fork main

Or use causet deploy --fork main --runtime ./concert-app/ --full for the golden path in one command.

In this section

Page	What it covers
Forks	What forks are, naming, staging vs production, test forks
Releases	IR artifacts, creating releases, versioning, rollback
Deployments	Deploying and activating a release on a fork

Next steps

Quickstart — compile and deploy your first app
Schema Versioning — safe IR changes across releases
Debugging — inspect entities and ledger events per fork

Examples Forks