scribe.

Big worlds.
Small changes.

Version control for game makers. Large assets, shared history, and your team in sync.

Explore the documentation
Illustrative workflow: World.scene is modified. Two new chunks are sent and six are reused. The change is accepted into shared history.
01

Built for big assets

Transfer the chunks that change.

02

One source of truth

An authoritative server. A shared history.

03

Your work, protected

Recovery comes before replacement.

BIG ASSETS. CONSIDERED TRANSFERS.

Move your world.
Transfer the change.

Upload only missing chunks. Reuse local data on sync. Verify every reconstructed file.

1 / 4 / 16 MiBMinimum / target / maximum chunk
256-bitBLAKE3 content identity
See how it works

THE WHOLE TEAM. THE WHOLE PROJECT.

It all comes together.

01

Branches without asset duplication.

Branch the metadata, share the assets. Merge only the paths that diverge.

02

Just your part of the world.

Sync the characters, audio, or code you need with selective workspace views.

03

Lock the assets that need it.

Repository-wide locks protect shared assets. You decide how binary conflicts resolve.

04

Your servers. Your permissions.

Shared identities, clear repository roles, and revocable tokens over TLS 1.3.

05

Storage and transfer, your call.

Independent LZ4 compression for storage and transfers. Incompressible data stays raw.

06

Built for your pipeline.

Revision exports, JSON output, integrity checks, and verified backup and restore.

YOUR SETUP. YOUR PACE.

Scales with you.

Start with one storage server. Add the pieces you need as your team, projects, and storage grow.

  1. 01

    Start small.

    Run scribe-server locally. No auth service, controller, or gateway required.

  2. 02

    Bring your team.

    Add scribe-auth for shared accounts and repository permissions over TLS.

  3. 03

    Simplify operations.

    Use scribe-ctl to provision and supervise local storage and auth from one TOML config.

  4. 04

    Expand your storage.

    Put scribe-gateway in front of multiple storage instances, with one endpoint for your clients.

The full setupOne possible setup. Auth and gateway are independently optional.
The full setupScribe clients connect to a gateway, which routes repository traffic to three storage instances. Each storage instance checks permissions with a shared auth service. The controller provisions and supervises the local storage and auth processes. The gateway runs separately.LOCAL STORAGE + AUTH SERVICESYour teamScribe clientsscribe-gatewayRoutes repositoriesscribe-ctlLocal supervisionStorage ARepositories + assetsStorage BRepositories + assetsStorage CRepositories + assetsscribe-authAccounts + rolesThe full setupScribe clients connect to a gateway, which routes repository traffic to three storage instances. Each storage instance checks permissions with a shared auth service. The controller provisions and supervises the local storage and auth processes. The gateway runs separately.LOCAL STORAGE + AUTH SERVICESYour teamScribe clientsscribe-gatewayRoutes repositoriesscribe-ctlLocal supervisionStorage Ascribe-serverStorage Bscribe-serverStorage Cscribe-serverscribe-authAccounts + roles

Storage stays authoritative. The gateway routes existing repositories and places new ones across storage instances.

One project. Every possibility.

  • Worlds & scenes
  • Textures & materials
  • Code & everything else

Server & client supported on

Windows · macOS · Linux

In development · Written in Rust

Under the hood

A SHORT PATH FROM IDEA TO SHARED HISTORY.

Change. Submit. Sync.

01

Make it yours

Open a tracked file for editing.

shell
scribe edit Assets/world.scene
02

Make it history

Publish the change to the server.

shell
scribe submit -m "Build a new world"
03

Bring everyone along

Bring a teammate's working copy up to date.

shell
scribe sync
Example workflow after setting up a repository and working copy.Follow the first-project tutorial

THE NEXT CHAPTER

Build worlds.
We'll keep the changes.

Get to know Scribe