scribe.
Download

Version control for game makers

Big worlds. Small changes.

A shared history for your assets, code, and all the people bringing your world to life.

Read the documentationHow it works
Illustrative workflow: World.scene is modified. Two new chunks are sent and six are reused. The change is accepted into shared history.

Made for big files

Only changed chunks travel.

One server decides

No arguing about which copy is real.

Nothing overwritten silently

Sync saves your changes before it replaces a file.

Transfers

Change a corner of a 2 GB level. Send the chunks that changed.

Scribe uploads only the chunks the server doesn't have, reuses what's already on your disk, and verifies every rebuilt file.

How transfers work
1 / 4 / 16 MiB
Minimum / target / maximum chunk
256-bit
BLAKE3 content identity

How much that saves depends on how your tools write files.

For the whole team

The unglamorous parts, done carefully.

As you grow

One server today. More when you need them.

Most teams start with a single storage server and add the rest when the team, the projects, or the disks ask for it.

  1. 01

    Just the server.

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

  2. 02

    Add accounts.

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

  3. 03

    Fewer terminals.

    Let scribe-ctl provision and supervise local storage and auth from one TOML file.

  4. 04

    More 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.

The project

Everything a game is made of, in one repository.

Holds
Levels & scenes · Textures & materials · Code, and that one spreadsheet
Server and client
Windows · macOS · Linux
Status
In development · Written in RustHow it's built

The daily loop

Three commands you'll type every day.

  1. 01

    Open it for edit

    Tell Scribe which file you're about to change.

    shell
    scribe edit Assets/world.scene
  2. 02

    Submit the change

    The server accepts it, or tells you why not.

    shell
    scribe submit -m "Move the waterfall two meters left"
  3. 03

    Everyone else syncs

    Teammates pull the accepted change into their working copies.

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

When you're ready

Build worlds. We'll keep the changes.

Set up a first server