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).
Casewhere is not a Git client
This is the key idea to understand before using the feature. Casewhere does not run Git. It only reads and writes files in a folder. That folder is an ordinary Git working tree that you (or your CI pipeline) manage with your normal Git tooling — git commit, push, pull, clone, branches, and pull requests all happen outside Casewhere.
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 (external Git 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 from folder, Export all, and per-resource Fetch From Folder |