Mega: a Rust monorepo engine that treats AI agents as committers

The context problem Mega is trying to sell you on

The README makes a specific argument: version control was designed for humans working in isolated branches, and AI coding agents need something different. The claim is that agents produce fewer hallucinations and make better decisions when they can see dependencies, downstream consumers, build targets and test coverage in one place, and that a monorepo is what makes that visibility possible. Mega is the server side of that argument. It is a centralized monorepo engine with trunk-based development and fine-grained access control, and the pitch is that it gives an agent the global view it needs for dependency analysis and impact assessment. The intended user is not a solo developer with a small repository. It is a team already committed to a monorepo, or one considering that move, and specifically a team that wants agent commits to land in the same history as human commits rather than in a parallel system. Whether the hallucination claim holds is not something this review can verify. What is verifiable is the design intent: Mega is positioned as infrastructure, not as an agent framework, and the README is explicit that humans and agents are meant to interact through the same Git interface.

Two processes, one history: how Mega and Libra split the work

Mega is not a single program. The README describes a client-server split. Mega runs server-side as the monorepo engine. Libra, a separate Rust project in the same family, runs on the agent side as a Git-compatible client with SQLite-backed storage. The stated reason for Libra is that agents should be able to clone, commit and push through a library rather than shelling out to git, and that those operations should carry structured metadata and intent tracking. The data flow the README implies is: an agent calls Libra, Libra speaks Git protocol to Mega, and Mega holds the trunk and the access control rules. Two further components appear in the same family. ScorpioFS is a FUSE filesystem that mounts any folder of the monorepo as a local filesystem, so a developer or agent can work without checking out the whole repository. Buck2 is the default build system. The important architectural point is that Mega does not require agents to use a proprietary protocol. The Git compatibility is the integration surface, and Libra is an optimization on top of it rather than a replacement for it. That is a meaningful design choice, because it means a plain git client can still talk to the server.

Git compatibility and the partial-clone workflow

The README's Git compatibility claim is concrete: you can clone or pull any folder in the monorepo into your local filesystem as a standard Git repository, and push changes back. This is the mechanism that makes a petabyte-scale monorepo usable on a laptop, and it is the same shape of solution as a partial clone or a sparse checkout, except the server is built to expect it rather than tolerate it. ScorpioFS attacks the same problem from a different angle. Instead of materializing a folder as a Git working tree, it mounts a monorepo folder as a FUSE filesystem, so file reads are served on demand and nothing is checked out ahead of time. The two approaches have different failure modes. A partial clone gives you a real Git repository with real object storage, which means ordinary Git tooling works, but you still pay for whatever you materialized. A FUSE mount gives you lazy access to everything, but every file access depends on the mount being healthy and the server being reachable. The README does not say which one the project recommends for which situation, and it does not discuss what happens to a FUSE mount when the network drops. That is a gap worth noting before you build a workflow on either.

Getting it running: Docker first, Buck2 second

The Quick Start section is short and defers to three documents: docker/README.md for a Docker demo, docs/development.md for native development, and docs/architecture.md for the architecture. The Docker path is described as recommended for a rapid deployment and hands-on experience, which suggests the native path has more prerequisites. The README confirms that suspicion in the contributing section, where it states that the project builds with Buck2 and that you should install Buck2 and cargo-buckal before development. The Buck2 install instructions are a manual download: fetch the release tarball for your platform from the facebook/buck2 releases page, extract it, and place the binary in ~/.cargo/bin so that it is on PATH. cargo-buckal is installed with cargo install --git https://github.com/buck2hub/cargo-buckal.git. The build command is cargo buckal build, and when you change dependencies in Cargo.toml you are told to run cargo buckal migrate to regenerate Buck metadata and third-party lockfiles. Before a pull request, the README requires three checks in order: cargo +nightly fmt --all, cargo clippy --all-targets --all-features -- -D warnings, and pnpm -C moon prettier --check . Clippy treats warnings as errors, so a single unused import fails the check. Note the mixed toolchain: Rust plus pnpm for a frontend directory named moon, plus Buck2 for the build graph. That is three package managers' worth of setup before you compile anything.

The build system is not optional, and that is the main adoption cost

Buck2 integration is listed as a feature, and the README justifies it on the grounds that declarative, reproducible and highly parallelized builds matter when humans and agents contribute to the same repository at the same time. The reasoning is sound for a large monorepo. The cost is that Buck2 is not a dependency you can skip for a quick evaluation. The README states plainly that the project builds with Buck2 and instructs you to install it before development, and the pull request requirements include a cargo buckal build step. If your team has no Buck2 experience, you are adopting two systems at once: Mega and a build tool with its own rule language and its own mental model. The cargo buckal migrate step adds a second cost that is easy to underestimate. Dependency changes in Cargo.toml require regenerating Buck metadata and third-party lockfiles, which means a routine version bump becomes a two-step operation that can drift if someone forgets the second step. The README does not describe what happens when the Buck metadata and Cargo.toml disagree, and it does not offer a Cargo-only fallback. For a team already on Buck2 this is free. For everyone else it is the largest line item in the migration.

What the README does not settle

Three items on the roadmap are named as future work: IntentSpec, a machine-readable intent contract that drives agent task execution with security policies and provenance binding; multi-agent DAG orchestration for coordinating several agents across multi-step code generation; and code attribution, which would track AI-generated versus human-written code at the line level. Read the README carefully and the agent-specific story is mostly in this section. The shipped features are Git compatibility, trunk-based development, Conventional Commits, ScorpioFS and Buck2. Conventional Commits support is real and useful for changelog automation, but it is a commit-message convention, not an attribution mechanism. If you need to answer the question of which lines came from an agent, the README says that capability is planned, not present. The same applies to the provenance and policy binding that IntentSpec would provide. This is not a criticism of a v0.1.0 project; it is a warning about reading the marketing line at the top of the README as a description of current state. The release history supports the caution: v0.0.8 in September 2025, v0.0.9 and v0.1.0 in March 2026. The project is early, and the version numbers say so.

Where Mega is the wrong tool, and what to use instead

Mega is the wrong tool for a repository that fits comfortably on one machine. If a full checkout takes seconds and your build graph is small, the Buck2 requirement alone will cost more than the monorepo engine saves, and a plain Git server plus CI will do the job. It is also the wrong tool if you want a single self-contained binary with no external build system, because the README ties the project to Buck2. The natural alternative for teams that want monorepo semantics without adopting a new server is the tooling already in Git: sparse checkout and partial clone against an ordinary Git host, combined with a build system you already run. The difference in approach is that sparse checkout is a client-side filter over a normal repository, so the server does nothing special and you keep your existing host, permissions and CI. Mega moves that logic into the server, which is what lets it enforce access control and serve folders on demand at a scale Git was not built for, but it also means the server is now a component you have to operate. If your problem is agent access rather than scale, a Git host with a documented API and a client library may be enough, and Libra's structured metadata and intent tracking are the part you would be giving up. The README does not compare Mega to any of these options, so the trade-off is left to the reader.

Maintenance, licensing and what to check before you commit

Maintenance burden comes from three places visible in the material. First, the toolchain: Buck2 is installed by downloading a release tarball by hand and placing the binary in ~/.cargo/bin, which is a manual step you repeat when you upgrade. Second, the dependency regeneration loop: cargo buckal migrate after every Cargo.toml change. Third, the multi-repository coupling: Mega, Libra and ScorpioFS are separate projects in the same family, and the README does not state a compatibility matrix between their versions. On licensing, the material is inconsistent and you should resolve it before adopting. The repository metadata supplied here says Apache-2.0, while the README's License section says Mega is licensed under an MIT LICENSE and links to LICENSE-MIT. The README text appears truncated at that point, so a second licence file may exist. Do not treat this review as legal advice; read both files in the repository and confirm which terms apply to the components you plan to deploy, including Libra and ScorpioFS, which are separate projects with their own licences. The concrete first step is to clone the repository, read docker/README.md and docs/architecture.md, and run the Docker demo before installing Buck2. If the demo does not cover your deployment target, the native path in docs/development.md is the next thing to read.

Editorial conclusion

Adopt Mega if you already run a large monorepo, want Git protocol compatibility rather than a proprietary client, and are prepared to install Buck2 plus cargo-buckal before your first build. Do not adopt it if you need a single-binary server with no external build toolchain, or if you depend on the IntentSpec, multi-agent DAG orchestration and line-level code attribution features, since the README lists all three as roadmap items rather than shipped capabilities. Verify first that the Docker demo in docker/README.md matches your deployment target, that the licence situation is settled (the README's License section points at an MIT file while the repository metadata says Apache-2.0), and that Libra, ScorpioFS and Mega version together in the way your workflow needs.

Official sources

1. gitmono-dev/mega on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases