Releases

A release is an immutable, versioned snapshot of your application’s compiled behavior. It bundles the IR artifacts the runtime, query service, and projection worker need to execute your rules, queries, and projection DDL.

Releases are created after compile — not from live .causet files at runtime.

What a release contains

Artifact	Consumed by	Purpose
`ruleset.vrd`	Runtime service	Compiled ruleset binary
`causet.projections.json`	Projection worker, query service	Projection DDL, handlers, query SQL
`causet-sdk-ir.json`	Tooling / SDK	Human-readable IR summary
`manifest.json`	Control plane	Hashes, build metadata, stats

Each published release has a tag (e.g. 1.0.0), a release ID, and a ruleset ID for integrity checks. Once published, artifacts do not change.

CLI workflow

Authenticate and set context once:

causet login
causet context use platform my-platform
causet context use app concert-app

1. Compile

causet build validate --runtime ./concert-app/
causet build compile  --runtime ./concert-app/ --out dist/

Outputs in dist/:

dist/ruleset.vrd
dist/causet.projections.json
dist/causet-sdk-ir.json
dist/manifest.json

Fix compiler errors before continuing. The compiler validates event references, projection fields, query from tables, and forbidden expressions.

2. Create a local release archive

causet release create --input dist/ --tag 1.0.0

Packages dist/ into a versioned .tar.gz archive on disk.

3. Publish to Causet Cloud

causet release publish --tag 1.0.0

Uploads the archive and registers an immutable release in the control plane. The command prints the release ID — use it in logs and CI.

Next: causet deploy apply --tag 1.0.0 --fork <fork>

Inspect and compare releases

# List releases (optional: show deploy status on a fork)
causet release list
causet release list --fork staging
 
# Full metadata for one tag
causet release inspect --tag 1.0.0
 
# Compare two tags
causet release diff --from 1.0.0 --to 1.1.0

For IR-level change analysis before deploy, use causet plan.

Golden path (compile + release in one command)

Skip manual release steps when deploying immediately — causet deploy runs validate → compile → release create → release publish → deploy apply → deploy activate:

causet deploy --fork staging --runtime ./concert-app/ --full

See Deployments for fork targeting and activation modes.

Release lifecycle

Local archive → Published (cloud) → Applied (candidate on fork) → Active (serving traffic)

State	Meaning
Published	`causet release publish` succeeded — ready to deploy
Applied	Staged on a fork via `causet deploy apply` — not yet live
Active	Promoted via `causet deploy activate` — serving intents and queries
Superseded	A newer tag is active on the same fork

You can publish any tag once and deploy it to multiple forks. Roll back by applying an older tag.

Versioning and rollback

Each activation updates the active IR version for the target fork. The runtime hot-reloads without dropping in-flight intents.

Rollback — apply and activate a previous tag:

causet deploy apply    --tag 1.0.0 --fork main
causet deploy activate --tag 1.0.0 --fork main --mode FULL

Note: Rollback reverts rules and query templates. Projection DDL is additive — columns from a rolled-forward release are not dropped automatically. See Schema Versioning.

Release notes in CI

Tag releases with semver or git SHA in CI:

TAG="1.2.0-$(git rev-parse --short HEAD)"
causet build compile --runtime ./concert-app/ --out dist/
causet release create  --input dist/ --tag "$TAG"
causet release publish --tag "$TAG"
causet deploy apply    --tag "$TAG" --fork staging
causet deploy activate --tag "$TAG" --fork staging --mode FULL

Document breaking changes in your PR / release notes — the CLI stores the tag; notes live in your repo or control plane title.

Next steps

Deployments — deploy apply and deploy activate
Forks — target environments
Schema Versioning — safe IR changes across releases

Forks Deployments