Your repo, your rules
Open-source, fully headless and completely customizable git infrastructure built for agentic workloads. Apply any workflow you can write in code in your own stack.
What you can build with it
Build on Enroute with full flexibility to scale your code workflows or bring version control to entirely new places. These are use-cases we see teams building on top of headless git infrastructure already today.
┌────────────────────┐│ coding agent │────┐ ┌────────────────┐ ┌────────────────────┐├────────────────────┤ │ │ │───────────────────▶│ ││ coding agent │────┼────▶│ enroute │ your rules │ your app │├────────────────────┤ │ │ │◀───────────────────│ ││ coding agent │────┘ └────────────────┘ └────────────────────┘└────────────────────┘a repo per task
┌────────────────────────┐│ coding agents │└────────────────────────┘│▼┌────────────────────────┐│ enroute │└────────────────────────┘│ your rules▼┌────────────────────────┐│ your app │└────────────────────────┘
Give every agent their own repo, or create a new repo per task. Spin-up as many as you need without any limits. Keep them around, or discard them as one-off. You control who can do what with your own systems.
Start building with agent skills
npx skills add enroute-sh/enroutecopyGoing custom is no longer the enemy
Stay ahead while the ground moves. Express any rule or workflow in code, on a stack you own. Host it anywhere that speaks HTTP. Enroute is fully headless and completely customizable via hooks.
Decide who gets access to your repos and for what. Enroute does not need to know your org chart or agents. Use your own data and grant access in a way that matches your risk profile: Per user, per repo, per use-case.
Build review strategies beyond the pull request. Decide which changes get reviewed by an agent and which need human oversight. Enroute calls your app after every interaction. You decide what happens next.
Protect your branch with your own rules. Changes only get applied if they comply. No settings page or yaml file needed.
Minimize the time it takes to pull from your repo. You decide what is visible on every fetch. Only serve your agents what they actually need.
The best-in-class provider today is legacy tomorrow. Connect your issue tracker or collaboration platform. Pick the sandbox that gives you the right level of abstraction over bare metal. Swap anytime.
┌──────────────────────────┐ ┌──────────────────────────┐│ │ │ ││ │◀─────────── authorize ──────────── │ ││ your app │ │ enroute ││ │ ──────────── decision ────────────▶│ ││ │ │ ││ │ │ │└──────────────────────────┘ └──────────────────────────┘
┌───────────────┐│ your app │└───────────────┘▲ authorize▼ decision┌───────────────┐│ enroute │└───────────────┘
$ git push origin main # dana, platform
remote: dana is not on the team that owns payments
fatal: unable to access 'https://acme.enroute.sh/payments.git/': 403
// enroute asks this on every git request, read or write.
async function authorize(request) {
// your identity provider, answering about your org chart.
const actor = await yourIdP.verify(request.headers);
if (!actor) return unauthorized(CHALLENGE);
// all of engineering reads. the owning team writes.
const mayWrite = actor.teams.includes(repo.team);
if (request.access === "ACCESS_WRITE" && !mayWrite) return forbidden();
return grant(repo.enrouteId, actor.id);
}
How it works
┌──────────────────────────────────────────────────────────────────────────────────────────┐│ ││ client ││ │└──────────────────────────────────────────────────────────────────────────────────────────┘│ ▲ hooks│ │▼ │╔═ git server ═════════════════════════════════════════════════════════════════════════════╗║ ║║ ┌───────────────────────────────────┐ ┌───────────────────────────────────┐ ║║ │ │ │ │ ║║ │ api │ │ git protocol │ ║║ │ │ │ │ ║║ └───────────────────────────────────┘ └───────────────────────────────────┘ ║║ ║║ ║╚══════════════════════════════════════════════════════════════════════════════════════════╝│ │ ││ │ │▼ ▼ ▼┌───────────────────────────┐ ┌───────────────────────────┐ ┌────────────────────────────┐│ │ │ │ │ ││ serverless compute │ │ postgres │ │ object storage ││ │ │ │ │ │└───────────────────────────┘ └───────────────────────────┘ └────────────────────────────┘
┌─────────────────────────┐│ client │└─────────────────────────┘│ ▲ hooks▼ │╔═ git server ════════════╗║ ║║ ┌──────────────────┐ ║║ │ api │ ║║ └──────────────────┘ ║║ ┌──────────────────┐ ║║ │ git protocol │ ║║ └──────────────────┘ ║║ ║╚═════════════════════════╝│▼┌─────────────────────────┐│ serverless compute │└─────────────────────────┘┌─────────────────────────┐│ postgres │└─────────────────────────┘┌─────────────────────────┐│ object storage │└─────────────────────────┘
Enroute is a highly scalable git platform built on top of object storage. Self-host it on any S3 compatible bucket. It's engineered to support any agentic workload: Unlimited repos, unlimited commits, no rate limits.
The git server is fully headless and accessible via gRPC API or git wire protocol. Your application doesn't hold any state. Anything git is handled by Enroute.
The server terminates git client connections and is controlled via gRPC API. Stateless, so it's easy to operate and scale.
Handling git pack files is compute intensive. Rather than limit clients or overprovision servers, Enroute uses serverless to scale out compute-heavy workloads.
Metadata that changes frequently is best stored in a transactional database. Enroute uses Postgres for storing ref tables, object indexes and data catalogs.
Commits, trees, blobs, and their respective graphs and indexes live in object storage. Enroute segments this data to optimize for common git access patterns, making the storage layer extremely fast and scalable.
▲ Get in touch
Your code needs a new home
Enroute is open source and free to self-host. Get started with our agent skills that help you scaffold your own git platform from scratch.
Or write to us: copy