English | 简体中文
Server-first source control for monorepos, coding agents and CI.
Scion is a Rust implementation of the design in Anthropic's Redesigning source control: history, merges and rebases are computed on the server, clients stay online and fetch immutable objects on demand, and a checkout holds only the paths a job needs. It ships a server, scion, and a client, scn, over a language-neutral protocol, and is built by OpenCSG for starhub-server and CSGLite.
CSG Scion vs. Git and CarterT27/scion on the OpenScion workloads, one Apple M5. Median ms, lower is better.
| Scenario | Git, 1k files | CarterT27, 1k | CSG Scion, 1k | Git, 10k files | CarterT27, 10k | CSG Scion, 10k |
|---|---|---|---|---|---|---|
| Import directory | 365.0 | 32.8 | 30.6 | 3,364.4 | 413.5 | 354.9 |
| Commit one changed file | 28.4 | 29.2 | 13.9 | 250.8 | 142.5 | 35.5 |
| Full clone / checkout | 243.0 | 115.8 | 52.2 | 2,361.9 | 1,047.3 | 589.4 |
| One-directory clone / checkout | 60.3 | 25.0 | 23.1 | 172.9 | 123.1 | 49.5 |
Fastest in every cell: 2–12× faster than Git, 1.1–4× faster than CarterT27/scion on checkouts and commits.
Real repository: pingdotgg/t3code, 5,573 commits and 28,068 files; CSG Scion on PostgreSQL and MinIO. The M4 Pro columns are from CarterT27/scion's README.
| Scenario | Git, M5 | CSG Scion, M5 | Git, M4 Pro | CarterT27, M4 Pro |
|---|---|---|---|---|
| Full checkout (28,068 files) | 2.13 s | 2.20 s | 2.90 s | 14.96 s |
Checkout of apps/web (1,521 files) |
0.173 s | 0.178 s | 0.21 s | 0.97 s |
| Clean status | 98 ms | 75 ms | — | — |
| Full history: Git's clone, Scion's import | 3.96 s | 103 s + 42 s repack | 3.56 s | 23 min 18 s |
| Storage of the history | 557 MB pack | 247 MB in MinIO + 90 MB in PostgreSQL | — | — |
Method and more: OpenScion workloads · starhub-server · component benchmarks
flowchart LR
scn["scn<br/>client"] --> daemon["scn daemon<br/>local cache"] --> cache["scion cache<br/>regional cache"] --> server["scion server<br/>commit · land · history"]
server --> meta[("SQLite / PostgreSQL")]
server --> blobs[("Local dir / S3")]
Commits are created and rebased on the server; clients fetch only the files they check out; history needs no clone. Also: scn import git with git SHAs kept, ACLs by repository, ref and path, and redaction.
# Install the client and run the server as a service on 127.0.0.1:7080 (Linux or macOS)
curl -fsSL https://raw.githubusercontent.com/OpenCSGs/scion/main/install.sh | sh -s -- --server
scn repo create http://127.0.0.1:7080/mono
scn clone http://127.0.0.1:7080/mono && cd mono
echo hello > README.md
scn commit -m "add readme"
scn land # move main to the commit; the server rebases if main moved
scn logWithout --server, the script installs only the client, scn. From source instead: cargo run -p scion -- server --lite --data-dir ./.scion-data and cargo install --path client/cli.
Know git? Most git commands work in scn as you type them, starting with scn clone http://host/REPO: see git commands in scn for the full list.
A tour of scion and scn goes through the everyday commands, and coming from git explains how the model differs.
# Client only
curl -fsSL https://raw.githubusercontent.com/OpenCSGs/scion/main/install.sh | sh
# Client and server, as a service on 127.0.0.1:7080
curl -fsSL https://raw.githubusercontent.com/OpenCSGs/scion/main/install.sh | sh -s -- --server
# For a team: listen on all interfaces with authentication on; prints the first admin token
curl -fsSL https://raw.githubusercontent.com/OpenCSGs/scion/main/install.sh | sh -s -- --server --listen 0.0.0.0:7080Runs under systemd on Linux (data in /var/lib/scion) or launchd on macOS (data in ~/Library/Application Support/scion). sh install.sh --help lists the options; release binaries covers installing by hand.
docker run -d --name scion -p 7080:7080 -v scion-data:/data opencsghq/scion:latest
docker exec scion scion admin token create --lite --subject admin --group admins # shown only once
scn login http://localhost:7080 --token scn_pat_…
scn repo create http://localhost:7080/monoThe image is built for linux/amd64 and linux/arm64 and requires authentication. Members of admins manage the server and anyone signed in can read, write and land; to change that, see access control.
docker run -d --name scion -p 7080:7080 \
-e SCION_META=postgres://scion:PASSWORD@db:5432/scion \
-e SCION_BLOBS=s3://scion-objects -e SCION_S3_ENDPOINT=https://s3.example.com \
-e SCION_S3_ACCESS_KEY_ID=… -e SCION_S3_SECRET_ACCESS_KEY=… \
opencsghq/scion:latest --log-format json server --listen 0.0.0.0:7080 --auth-required
docker exec scion scion admin token create --subject admin --group adminsSeveral nodes behind a load balancer share one database and bucket (clusters). To try it all on one machine, deploy/compose starts PostgreSQL, SeaweedFS and the server.
Each user or CI job signs in once with scn login SERVER scn_pat_… (or sets SCION_TOKEN). An administrator creates tokens with scion admin token create --subject alice, where alice is the user's name as commands and policies see it, adding --group admins for another administrator or --ttl 90d for expiry:
| Deployment | Command |
|---|---|
| install script, Linux | sudo -u scion scion admin token create --lite --data-dir /var/lib/scion --subject alice |
| install script, macOS | scion admin token create --lite --data-dir ~/Library/Application\ Support/scion --subject alice |
| Docker, one node | docker exec scion scion admin token create --lite --subject alice |
| Docker Compose or production | docker compose exec scion scion admin token create --subject alice |
With an OIDC provider or a GitHub OAuth app configured, people sign in with scn login SERVER in a browser instead. Organizations (scn org), personal namespaces and several authorization sources can be combined: the policy, GitHub teams, and webhooks such as starhub or OPA. Deployment and authentication have the details.
| Use | Deploy · CLI tour · Git commands · Coming from git · Git import · Sparse checkout · Repos · Archives · Browse · Git SHAs |
| Operate | Storage · Clusters · Caching · Auth · Redaction · Events · Observability |
| Design | Server · Client · starhub · Object format · Protocol |
- M1–M4: write path, working copy, history, server-side landing, clusters, caches
- M5, production hardening: auth, redaction, observability, events, packs and release builds done; YugabyteDB and Helm remain
Details: milestones · roadmap
cargo test --workspace
cargo clippy --workspace --all-targets -- -D warningsDevelopment describes the repository layout, the dependency rules between crates and the testing requirements (at least 90% coverage of new code).
Apache-2.0