Source control overview

Casewhere can mirror your entire solution configuration to a Git-tracked folder, giving you proper version control over configuration: history, branching, diffs, and pull-request review — alongside the runtime that actually serves your users.

Source control is available in Casewhere 2.9.9 and later. You find it under Deployment → Source Control in Casewhere Admin. It is enabled per environment by an application setting (see Enable and configure).

The runtime is never a Git repository

This is the key idea to understand before using the feature. The mechanism that mirrors configuration — the folder store — only reads and writes files in a folder. It is never itself a Git repository. That folder is an ordinary Git working tree, and the actual Git operations (commit, push, pull, clone, branches, pull requests) run against the folder — driven either by your own Git tooling or by the built-in Git menu on the Source Control page.

So you have two equally valid ways to work: manage the folder entirely with external Git tooling (or CI), or use the in-app Git toolbar for everyday operations. Either way, the runtime stays out of it — Synchronize configuration covers both.

Casewhere's runtime backbone is unchanged: Event Sourcing and MongoDB remain the source of truth at runtime. The folder is the source of truth for version control — the two are kept in sync automatically.

flowchart LR
    RT[("Casewhere runtime<br/>Event Sourcing + MongoDB")] <-->|"export on save / reload"| FOLDER["Git-tracked folder<br/>one JSON file per resource"]
    FOLDER <-->|"commit · push · pull<br/>(built-in Git menu or your own tooling)"| REMOTE[("Remote repository<br/>GitHub / Azure DevOps")]
    style FOLDER fill:#1f6feb,color:#ffffff,stroke:#11448a

What gets versioned

Every configuration resource is written as a single JSON file, laid out by type:

<folder>/<EntityType>/<resource-name>.<id>.json

For example a data class, a workflow definition, a rule, a widget, a theme, a worker site, or a product each becomes one file under a folder named after its type. The trailing id makes every file uniquely locatable, so a rename replaces the same file and a delete never leaves an orphan behind.

The serialization is deliberately Git-friendly, so diffs are small and readable:

• Indented JSON, UTF-8 without BOM, and LF line endings for stable cross-platform diffs.
• Multi-line code fields — scripts, expressions, and rules — are stored as arrays of lines rather than one escaped string, so a one-line code change shows as a one-line diff.
• Audit metadata is retained in the files, so the runtime cache can be fully rebuilt from the folder.

How it relates to DevOps packages

Source Control and DevOps packages are complementary, and both live under the Deployment section:

	Source Control	DevOps packages
Purpose	Continuous version control of all configuration	Curated, releasable bundles of selected resources
Granularity	Every resource, automatically	The resources you add to a package
Mechanism	Git-tracked folder of JSON files	Export/import of a package across environments
Best for	History, branching, diffing, code review	Promoting a release from DEV → QA → PROD

Use Source Control to track and review how configuration changes over time, and DevOps packages to promote a chosen set of changes between environments.

In this section

Topic	Description
Enable and configure	Turn the feature on, point it at a Git working tree, and seed the folder
Synchronize configuration	Automatic export, Reload/Export, the built-in Git menu, Zip Push Deploy, and per-resource Fetch From Folder