Mega is Google Piper with a Rust server, a FUSE mount and a Buck2 build

The claim is scale, and it is made in the first paragraph

The README opens by naming its model: Mega is an open-source implementation of Google Piper, and the link it points to is a 2016 Communications of the ACM article about why Google stores billions of lines of code in a single repository. So the ambition is explicit rather than inferred. It describes itself as Git compatible and purpose-built for AI-native engineering workflows, written entirely in Rust, and designed to manage petabyte-scale codebases while serving as the infrastructure backbone for AI coding agents. The argument for a monorepo in this project is not about developer convenience, it is about agent behaviour. The premise is that today's version control systems were designed for human developers working in isolated branches, and therefore lack the unified context, structured metadata and programmatic interfaces an agent needs to operate reliably at scale. Given that context, the stated benefits are that an agent which can see dependencies, downstream consumers, build targets and test coverage makes better decisions, produces fewer hallucinations, and can deliver atomic cross-project changes in a single commit. Two supporting mechanisms are described as present rather than planned. Commit messages follow the Conventional Commits convention, which the README ties to automated changelogs, semantic versioning and audit trails, all of which are machine-readable outputs an agent can produce correctly. And compatibility is at the protocol level rather than the tool level: you can clone or pull any folder in the monorepo into your working directory as an ordinary Git repository and push changes back, so a developer or an agent that already speaks Git needs nothing new to start.

Written entirely in Rust, and detected as TypeScript

There is a discrepancy in the repository metadata that is worth naming because it will confuse anyone deciding what this is. The README states the project is written entirely in Rust, and the build system, the workspace manifest and the dependency list are all Rust. GitHub reports the primary language as TypeScript. The tree explains why without contradicting either statement: there is a moon directory, which is the workspace tool that provides the pnpm-based frontend commands the contributing guide tells you to run, and the pre-submission checks include a Prettier invocation scoped to that workspace. So the project has a JavaScript toolchain around its Rust core, and language detection picks up the configuration rather than the code. This is a small thing, but it is the kind of detail that makes a repository look like a JavaScript project on a directory listing when it is not one, and it is worth checking the build files rather than the badge before forming an impression.

Fifteen workspace crates, and only four are built by default

The workspace manifest is the clearest map of the system. Fifteen members are listed: an API model crate, ceres, two client crates for orion and the scheduler, a common crate, io-orbit, jupiter with a nested callisto crate, jupiter-migrate, mono, three orion crates covering the core, the scheduler and the server, saturn and vault. The default members are four of them, mono, orion, orion-server and orion-scheduler, which tells you that the rest are support crates you get when something depends on them rather than targets you build on their own. The edition is 2024 and the resolver is version 3, so this is a current toolchain rather than something pinned to an older Rust. The dependency set describes what the server actually does: Tokio for the async runtime, axum and tower with tower-http and tower-sessions for the HTTP layer, sea-orm and sea-orm-migration for the database and its migrations, thiserror and anyhow for error handling, clap for the command line, tracing with a subscriber and an appender for logs, russh for SSH, lettre for email over SMTP with rustls, and two external crates named git-internal at 0.9.0 and libvault at 0.4.0, which are the only dependencies in the list that are not from a general-purpose ecosystem. The rest of the tree is organised around those crates and the tooling: Buck configuration at the root alongside a Buck file, a gitmodules and a libraignore, a rustfmt configuration, plus api-model, ceres, clients, common, config, io-orbit, jupiter, jupiter-migrate, mono, moon, orion, orion-server, orion-scheduler, saturn and vault, and the ci, docker, docs, scripts, tests and tmp directories. Names like orion, jupiter, saturn, ceres and vault are internal code names, which is the project's convention rather than a description of function.

Scorpio mounts a folder as a filesystem so nobody checks out the repository

This is the piece that makes a petabyte claim practical, and it lives in a separate repository. Scorpio is a FUSE filesystem that mounts any folder in the monorepo as a local filesystem. The described effect is that developers and agents work with their codebase as if it were local while Mega handles the scale underneath, with no need to check out the entire repository. That is a materially different operating model from Git, where working on a folder means materialising it, and it is the reason a monorepo engine can claim to serve codebases that would not fit on a developer's disk. The second external piece is Libra, the agent-side client, described as lightweight and embeddable, optimized for programmatic access, with SQLite-backed storage, and used by agents to clone, commit and push with structured metadata and intent tracking and explicitly no shelling out to the git binary. The division of labour the README describes is server versus client: Mega is the centralized engine holding global visibility, Libra is what an agent actually calls.

The build is Buck2, and a dependency bump needs a migration command

The contributing guide is the most demanding document in the repository, and it starts with a toolchain you have to install by hand. Buck2 is the default build system, described as Meta's Rust implementation of a declarative, reproducible and highly parallelized build, and developing against it requires both Buck2 and a wrapper called cargo-buckal. Installing Buck2 means downloading a release tarball from its GitHub releases, extracting it and placing the binary in the cargo bin directory, which the guide confirms must be on your path, and installing the wrapper means a cargo install from a Git repository rather than from crates.io. Once that is in place, three things follow. Every pull request has to pass the Buck2 build itself with cargo buckal build. Updating dependencies in Cargo.toml is not enough on its own, because the Buck metadata and third-party lockfiles have to be regenerated with cargo buckal migrate. And the three pre-submission checks are ordered, with the Rust format pass first, clippy second and the frontend formatting check third. The commands are short enough to be worth quoting exactly, because the flags are the point:

# 1. Format Rust code (apply fixes)
cargo +nightly fmt --all

# 2. Lint Rust (warnings are errors)
cargo clippy --all-targets --all-features -- -D warnings

# 3. Check frontend formatting
pnpm -C moon prettier --check .

The guide also gives a non-writing form of the format check for use the way continuous integration runs it, and a write form of the Prettier check for fixing drift locally.

Clippy treats warnings as errors and Prettier runs through a moon workspace

The three checks are short enough to run before every push, and the flags in them tell you what the project considers non-negotiable. Formatting uses nightly Rust rather than stable, so the command is cargo +nightly fmt --all, and the same command with a check flag verifies without writing files, which is the form continuous integration uses. Linting runs clippy across all targets with all features enabled and warnings promoted to errors, and the README states plainly that clippy treats warnings as errors and that Prettier must report no formatting drift. The frontend check is a pnpm command scoped to the moon directory, and a matching write variant is given for fixing it. So a change that is correct can still fail review for a formatting difference, and a warning in a feature-gated code path can fail a build that passes in the default configuration, because the lint command turns on every feature at once. Three licence files sit at the root as well, one for MIT, one for Apache and one for third-party code. On release cadence, the tags are v0.0.8 from September 2025, v0.0.9 in early March 2026 and v0.1.0 a day later, carrying an infrastructure-redefined-for-agents name; the repository is not archived and its default branch was last pushed on 16 September 2026. The development loop the contributing guide describes is ordinary in outline: clone, install the dependencies, initialize the database schema, run the test suite locally, then pick up an issue and open a pull request for community review. The community itself is a Discord channel linked from the README, with the longer contributor guidance kept in a separate document in the docs directory.

The roadmap is three agent features, none of them shipped

The last section of the README is a roadmap, and reading it as a plan rather than a feature list is the honest way to use it. Three items are named. IntentSpec is a structured, machine-readable intent contract intended to drive agent task execution with security policies and provenance binding, which is an attempt to make an agent's task something reviewable before it runs rather than a sentence in a chat window. Multi-Agent DAG orchestration is a pipeline architecture for coordinating several agents across multi-step code generation. And code attribution is line-level tracking of which lines were generated by a model and which were written by a person, offered as a way to make agent contributions auditable. All three are described as things Mega is evolving toward, and none appears in the feature list above them. The features that are described as present are the ones to plan on: full Git protocol support with per-folder clone and pull, trunk-based development as the working model, Conventional Commits for machine-readable messages, the FUSE mount, and the Buck2 build.

Editorial conclusion

Adopt Mega if you are running a monorepo at a scale where checking out a folder is not reasonable, and if your coding agents need dependency and impact information that a per-repository Git remote cannot give them. The pieces that make it usable are the Git protocol compatibility, the FUSE mount that avoids a checkout, and the server-side context the project claims to hold. Do not adopt it on the strength of the roadmap, because IntentSpec, multi-agent orchestration and line-level attribution are listed as things the project is evolving toward rather than things it does. Four things to check first. What state the server is in, given that the newest release tag is 0.1.0 from March 2026. Whether you can run the required toolchain, which means nightly Rust for formatting, clippy with warnings as errors, a moon workspace with pnpm for the frontend, and Buck2 with cargo-buckal for the build. Whether your licence expectations are met, since three licence files sit in the root. And whether the ecosystem pieces are what you need, because the agent-side client and the FUSE filesystem live in separate repositories.

Frequently asked questions

Official sources

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