v0.3.0

Enroute 0.3.0 is here, and it's our biggest release yet 🚀

Databases have changed a lot in the last decade. Git servers haven't. Enroute 0.3.0 replaces the storage engine with one we rebuilt from scratch on the principles of modern databases, and it's open source.

The result: over 7,500 pushes per second to a single repository, with every push on the disks of a majority of ledger nodes before Enroute acknowledges it. There's no Postgres, no Lambda worker, and no git gc to schedule. Just one binary and a bucket.

📖 Read how it works, and why we built it this way: Everyone is doing Git on S3 wrong

Try it in 30 seconds

1. Install: curl -fsSL https://enroute.sh/install | sh
2. Run the dev server: enroute dev
3. In another terminal, push a repo: git push http://127.0.0.1:8080/hello.git main
4. List it: enroute repo list

The Quickstart takes it from there.

What changed under the hood

• Compute and storage are separate. The bucket is the durable home for your data. Compute nodes only cache it, so a node can start cold and serve at once, and you can add or replace nodes at any time.
• Built natively for object storage. Each repository is a set of immutable layers in S3, Google Cloud Storage, Azure Blob Storage or a local directory. New pushes add layers, and Enroute merges them in the background.
• A replicated ledger is the commit point. A push completes when a majority of ledger nodes acknowledge it, not when the object store answers.
• Pushes are optimistic. Packs are checked in parallel without locks. Only the final ref update is a compare-and-swap, so pushes to different branches never conflict, and readers always see an immutable snapshot.

Grows with you

The same binary runs everywhere. Only the [node] section of the configuration changes:

1. One node on your laptop or a single server.
2. Separate compute nodes behind a load balancer when you need more Git and API capacity.
3. Three or five ledger nodes with Raft when writes must survive the loss of a machine or an availability zone.

For more information, see Deployment profiles.

Also new

• 🧑‍💻 Local dev in one command. enroute dev runs a node with no setup. Push to a new repository and it's there.
• 📦 Native installs. Binaries for Linux and macOS, no container needed.
• ✍️ Commits from your app. Your application can make commits directly through the API, without a Git client or a checkout.
• 🗂️ Folders for repositories. Group repositories with /, for example acme/widgets.
• 🛠️ A real CLI. Manage repositories, refs and commits, and check the health of a deployment, from the command line.

⚠️ Upgrading from 0.2.0

Because the engine is new, 0.3.0 can't read repositories that 0.2.0 wrote, and there's no migration. Start with an empty bucket and push your repositories again. Enroute tells you at startup which 0.2.0 configuration keys to replace.

Get it

The binaries for Linux (x86_64 and arm64, glibc 2.28 or later) and macOS (Apple silicon) are attached below, with SHA256SUMS to verify them. The container image is ghcr.io/enroute-sh/enroute:0.3.0, for amd64 and arm64.

Building on Enroute with a coding agent? Add our agent skills with npx skills add enroute-sh/enroute.

v0.2.0

Enroute 0.2.0 is here, and is now even easier to host yourself! 🎉

That's because there is less to configure, nothing to build, and fewer secrets to rotate:

• One install serves one application, so there is no tenant file to manage. A repository is addressed by the key your application gave it: RepoKey replaces the tenant and repository id on every call, and ListRepositories pages by key and can narrow by a prefix.
• One ingest function can serve every deployment, so there is no function or secret per deployment to configure and rotate. It now supports Lambda tenant isolation, and each bucket's credentials are either sent on the call or taken from the function's environment, as you configure.
• Additionally, the Docker image ships the ingest worker too, so the server and the function are one artifact at one version, and nothing needs to be built from source.

If you're upgrading from 0.1.0:

• This release breaks the contract and the configuration. Clients move to RepoKey. A deployment removes its tenant file and sets the keys in config (see docs/operate/configuration.md).
• The database migrates itself, and each repository keeps the name its tenant gave it. The migration stops if two live repositories in different tenants share a name.

Images are published as ghcr.io/enroute-sh/enroute for linux/amd64 and linux/arm64.