A monorepo without the hassle

Vex stitches selected physical repositories into one flat working checkout. Teams and agents can navigate a connected system while every path keeps its durable owner, history, and GitHub home.

How federation works

A monorepo workflow without a monorepo migration.

Home is one working view, not one new physical store. Submission routes work back to each repository owner, while each component keeps its own landing boundary.

Repository federationOne Home checkout
webgithub.com/acme/web
apigithub.com/acme/api
workergit.example.com/acme/worker
registered in
Versioned Home manifest
apps/web← web @ main
services/api← api @ main
services/worker← worker @ main
vex clone acme/home resolves
Flat Home checkout
apps/web/ services/api/ services/worker/

Submit edits by path

apps/web → web revisionservices/api → api revisionservices/worker → worker revision
One aggregate Change can show the cross-path submission. Each child revision stays with its owning repository, and landing remains scoped to that component.
The Vex Repos screen showing Home as a monorepo and the jj repository registered under Home, with its GitHub origin and Ready status.

Running product

Home and jj remain separately addressable while jj is registered inside the shared Home and keeps its GitHub identity.

This registry proves federation state, not aggregate cross-repository landing.

/vex/repos
Vex organization · 11 Aug 2026

01

Register

Map physical repositories to non-overlapping paths in a versioned Home manifest.

02

Resolve

Clone one flat Vex and Jujutsu working copy with vex clone <org>/home.

03

Work

Read and edit connected code without erasing repository ownership boundaries.

04

Route

Submit from Home and create revisions in the repositories that own each path.

Start with proof

Prove one Home across the repositories you already own.

Plan a multi-repo pilot Book a call