Skip to content

Releases: web3infra-foundation/mega

v0.1.0 - Infrastructure Redefined for the AI Agent Era

07 Mar 00:48
Immutable release. Only release title and notes can be modified.
5d7ec94

Choose a tag to compare

We are pleased to announce the release of Mega version 0.1.0, marking a significant milestone in our development of a Git-compatible, petabyte-scale monorepo engine tailored for large-scale codebases. Designed as an infrastructure platform specifically engineered for AI Agents, Mega facilitates atomic changes, consistent builds, and AI-native engineering workflows, drawing inspiration from Google's internal Piper system while ensuring full compatibility with standard Git operations. This version introduces enhanced integration with Libra, our evolving AI agent-native version control tool, to establish a comprehensive workflow for Agent version management. Together, Mega and Libra enable seamless trunk-based development, enforcement of Conventional Commits, and declarative builds via Buck2, empowering developers to manage expansive repositories with precision and efficiency. For detailed installation instructions and usage guidelines, please refer to the documentation in the repository.

Why Mega?

As AI coding agents become first-class participants in software development, the infrastructure beneath them must evolve. Traditional version control systems were designed for human developers working in isolated branches. Mega is designed from the ground up to serve both humans and AI agents at scale — providing the monorepo foundation that agents need to understand full codebase context, make atomic cross-project changes, and operate with minimal hallucination.
Inspired by Google Piper, Mega brings enterprise-grade monorepo management to the open-source world — now with a clear focus on the agentic future.

Mega — Because the agents need infrastructure too.

What's in v0.1.0

  • Git-Compatible Monorepo Engine — Full Git protocol support with trunk-based development. Clone, pull, or push any folder in the monorepo as a standard Git repository.
  • Scorpio (FUSE Filesystem) — Mount monorepo directories as local filesystems, giving AI agents and developers seamless, on-demand access to any part of the codebase without full checkout.
  • Buck2 Integration — First-class support for Meta's Buck2 build system, enabling declarative, reproducible builds across the entire monorepo.
  • Built with Rust — From the storage engine to the network layer, Mega is written entirely in Rust for memory safety, performance, and reliability at scale.

Mega + Libra: A Complete Workflow for AI Agent Version Control

Starting with this release, Mega and Libra — our Rust-based, Git-compatible client with SQLite-backed storage — together form a complete version control workflow purpose-built for AI agents:

  • Mega serves as the centralized monorepo backbone, managing code at scale with full context visibility — exactly what AI agents need to reason about dependencies, impact analysis, and cross-project changes.
  • Libra operates on the agent side as a lightweight, embeddable Git client optimized for programmatic access — enabling agents to clone, commit, and push with structured metadata and intent tracking.

Together, they unlock a new paradigm: version control in which AI agents are not just consumers of code but tracked, attributable contributors — with full provenance from intent to merge.

Looking Ahead

This is just the beginning. Our roadmap includes deeper agent integration — structured intent specs (IntentSpec), DAG-based task orchestration for multi-agent pipelines, line-level AI/human code attribution, and tighter coupling between Mega's monorepo context and agent decision-making. We're building the infrastructure layer that the agentic coding era demands.

Docker Images

  • ghcr.io/web3infra-foundation/mono-engine:v0.1.0
  • ghcr.io/web3infra-foundation/ui:v0.1.0
  • ghcr.io/web3infra-foundation/orion-server:v0.1.0

Quick Start

1 Clone the repo

git clone https://github.com/web3infra-foundation/mega.git
cd mega

2 Configure environment (optional)

Hosts mapping (required for demo domains)

The demo uses virtual domains under gitmono.local. Add the following line to your operating-system hosts file so that the browser resolves them to your local machine:

127.0.0.1 app.gitmono.local git.gitmono.local api.gitmono.local auth.gitmono.local orion.gitmono.local

On Linux/macOS this is /etc/hosts; on Windows it is C:\Windows\System32\drivers\etc\hosts. You can remove the mapping at any time after testing.

The demo environment already has sensible default values and can be used as-is. To customize any settings, create a .env file under docker/demo/:

cd docker/demo
# (Optional) copy `.env.example` to `.env` and edit as needed

The main configurable environment variables include:

  • Database Configuration:

    • POSTGRES_USER: PostgreSQL username (default: postgres)
    • POSTGRES_PASSWORD: PostgreSQL password (default: postgres)
    • POSTGRES_DB_MONO: PostgreSQL database name (default: mono, shared by Mega + Orion Server)
    • MYSQL_ROOT_PASSWORD: MySQL root password (default: mysqladmin)
      • ⚠️ For production, create a dedicated low-privilege user and update the MySQL health-check accordingly (avoid embedding root password).
    • MYSQL_DATABASE: Campsite database name (default: campsite, uses MySQL)
  • Service Images:

    • MEGA_ENGINE_IMAGE: Mega backend image (default: public.ecr.aws/m8q5m4u3/mega:mono-0.1.0-pre-release)
    • MEGA_UI_IMAGE: Mega UI image (default: public.ecr.aws/m8q5m4u3/mega:mega-ui-demo-0.1.0-pre-release)
    • CAMPSITE_API_IMAGE: Campsite API image (default: public.ecr.aws/m8q5m4u3/mega:campsite-0.1.0-pre-release)
    • CAMPSITE_RUN_MIGRATIONS: Whether to run database migrations when the container starts; 1 (default) to run, can be changed to 0 after the first successful migration to skip and speed up subsequent starts.
  • RustFS Configuration:

    • RUSTFS_ACCESS_KEY: RustFS access key (default: rustfsadmin)
    • RUSTFS_SECRET_KEY: RustFS secret key (default: rustfsadmin)
  • Mega Backend Configuration:

    • MEGA_MONOREPO__ADMIN: Add your GitHub login name here to grant admin access (comma-separated for multiple users)(default: Null)

Note: The demo environment uses default passwords and test users for demonstration purposes only.

3. Start all services

Execute in the project root directory:

docker compose -f docker/demo/docker-compose.demo.yml up -d

This command will:

  1. Pull the required Docker images (may take a long time for the first run)
  2. Create Docker networks and volumes
  3. Start all services in dependency order:
    • First, start infrastructure services (PostgreSQL, MySQL, Redis, RustFS)
    • Then, start application services (Mega, Orion Server, Campsite API)
    • Finally, start client services (Mega UI, Orion Build Client)

4. Check service status

View the status of all services:

docker compose -f docker/demo/docker-compose.demo.yml ps

View service logs (follow):

docker compose -f docker/demo/docker-compose.demo.yml logs -f

View logs for specific services:

docker compose -f docker/demo/docker-compose.demo.yml logs -f mega
docker compose -f docker/demo/docker-compose.demo.yml logs -f orion_server

5. Wait for services to become ready

On the first startup, services may take some time to finish:

  • Database initialization: PostgreSQL and MySQL need to initialize the databases
  • Service health checks: Each service waits for its dependencies to become healthy before starting
  • Image build: If using locally built images, the mega and orion_server services need to be built from source (slower on the first run)
  • PostgreSQL init script: On the very first launch, the container runs docker/demo/init-db.sh automatically (mounted into /docker-entrypoint-initdb.d/). The script does not create extra schemas; it simply prints helpful hints and reminds you that the mono database is auto-created by the POSTGRES_DB variable. Because the PostgreSQL data directory is persisted in the postgres-data volume, this script is executed only once unless you delete the volume.

Typically, you should wait 2–5 minutes. You can monitor service health with the following command:

# View the health status of all services
docker compose -f docker/demo/docker-compose.demo.yml ps

When all services show a status of healthy or running, you can start using the demo.


Demo walk-through

1. Open Mega UI

Open your browser and visit:

http://app.gitmono.local

2. Sign in with the test user

The demo environment includes a built-in test user you can use directly:

  • Username: mega (or as configured by MEGA_AUTHENTICATION__TEST_USER_NAME)
  • Token: mega (or as configured by MEGA_AUTHENTICATION__TEST_USER_TOKEN)

3. Trigger an Orion build

In Mega UI:

  1. Create a new monorepo project or select an existing one
  2. On the project page, find the build-related features
  3. Trigger a Buck2 build task
  4. The build request will be sent to Orion Server and executed by Orion Build Client

4. View build results

  • View in the UI: Build status and logs are displayed in Mega UI

  • View build client logs:

    docker compose -f docker/demo/docker-compose.demo.yml logs -f orion_build_client
  • View Orion Server logs:

    docker compose -f docker/demo/docker-compose.demo.yml logs -f orion_server

5. Access the RustFS console (optional)

RustFS object storage provides a web console:

http://localhost:9001/rustfs/console/access-keys

Log in with the following credentials:

  • Access Key: rustfsadmin (or the value of `RUSTFS_ACCESS_K...
Read more

v0.0.9

06 Mar 09:49
Immutable release. Only release title and notes can be modified.
5d7ec94

Choose a tag to compare

Mega Release

Version: v0.0.9


Table of Contents


Quick Start

1 Clone the repo

git clone https://github.com/web3infra-foundation/mega.git
cd mega

2 Configure environment (optional)

Hosts mapping (required for demo domains)

The demo uses virtual domains under gitmono.local. Add the following line to your operating-system hosts file so that the browser resolves them to your local machine:

127.0.0.1 app.gitmono.local git.gitmono.local api.gitmono.local auth.gitmono.local orion.gitmono.local

On Linux/macOS this is /etc/hosts; on Windows it is C:\Windows\System32\drivers\etc\hosts. You can remove the mapping at any time after testing.

The demo environment already has sensible default values and can be used as-is. To customize any settings, create a .env file under docker/demo/:

cd docker/demo
# (Optional) copy `.env.example` to `.env` and edit as needed

The main configurable environment variables include:

  • Database Configuration:

    • POSTGRES_USER: PostgreSQL username (default: postgres)
    • POSTGRES_PASSWORD: PostgreSQL password (default: postgres)
    • POSTGRES_DB_MONO: PostgreSQL database name (default: mono, shared by Mega + Orion Server)
    • MYSQL_ROOT_PASSWORD: MySQL root password (default: mysqladmin)
      • ⚠️ For production, create a dedicated low-privilege user and update the MySQL health-check accordingly (avoid embedding root password).
    • MYSQL_DATABASE: Campsite database name (default: campsite, uses MySQL)
  • Service Images:

    • MEGA_ENGINE_IMAGE: Mega backend image (default: public.ecr.aws/m8q5m4u3/mega:mono-0.1.0-pre-release)
    • MEGA_UI_IMAGE: Mega UI image (default: public.ecr.aws/m8q5m4u3/mega:mega-ui-demo-0.1.0-pre-release)
    • CAMPSITE_API_IMAGE: Campsite API image (default: public.ecr.aws/m8q5m4u3/mega:campsite-0.1.0-pre-release)
    • CAMPSITE_RUN_MIGRATIONS: Whether to run database migrations when the container starts; 1 (default) to run, can be changed to 0 after the first successful migration to skip and speed up subsequent starts.
  • RustFS Configuration:

    • RUSTFS_ACCESS_KEY: RustFS access key (default: rustfsadmin)
    • RUSTFS_SECRET_KEY: RustFS secret key (default: rustfsadmin)
  • Mega Backend Configuration:

    • MEGA_MONOREPO__ADMIN: Add your GitHub login name here to grant admin access (comma-separated for multiple users)(default: Null)

Note: The demo environment uses default passwords and test users for demonstration purposes only.

3. Start all services

Execute in the project root directory:

docker compose -f docker/demo/docker-compose.demo.yml up -d

This command will:

  1. Pull the required Docker images (may take a long time for the first run)
  2. Create Docker networks and volumes
  3. Start all services in dependency order:
    • First, start infrastructure services (PostgreSQL, MySQL, Redis, RustFS)
    • Then, start application services (Mega, Orion Server, Campsite API)
    • Finally, start client services (Mega UI, Orion Build Client)

4. Check service status

View the status of all services:

docker compose -f docker/demo/docker-compose.demo.yml ps

View service logs (follow):

docker compose -f docker/demo/docker-compose.demo.yml logs -f

View logs for specific services:

docker compose -f docker/demo/docker-compose.demo.yml logs -f mega
docker compose -f docker/demo/docker-compose.demo.yml logs -f orion_server

5. Wait for services to become ready

On the first startup, services may take some time to finish:

  • Database initialization: PostgreSQL and MySQL need to initialize the databases
  • Service health checks: Each service waits for its dependencies to become healthy before starting
  • Image build: If using locally built images, the mega and orion_server services need to be built from source (slower on the first run)
  • PostgreSQL init script: On the very first launch the container runs docker/demo/init-db.sh automatically (mounted into /docker-entrypoint-initdb.d/). The script does not create extra schemas; it simply prints helpful hints and reminds you that the mono database is auto-created by the POSTGRES_DB variable. Because the PostgreSQL data directory is persisted in the postgres-data volume, this script is executed only once unless you delete the volume.

Typically you should wait 2–5 minutes. You can monitor service health with the following command:

# View the health status of all services
docker compose -f docker/demo/docker-compose.demo.yml ps

When all services show a status of healthy or running, you can start using the demo.


Demo walk-through

1. Open Mega UI

Open your browser and visit:

http://app.gitmono.local

2. Sign in with the test user

The demo environment includes a built-in test user you can use directly:

  • Username: mega (or as configured by MEGA_AUTHENTICATION__TEST_USER_NAME)
  • Token: mega (or as configured by MEGA_AUTHENTICATION__TEST_USER_TOKEN)

3. Trigger an Orion build

In Mega UI:

  1. Create a new monorepo project or select an existing one
  2. On the project page, find the build-related features
  3. Trigger a Buck2 build task
  4. The build request will be sent to Orion Server and executed by Orion Build Client

4. View build results

  • View in the UI: Build status and logs are displayed in Mega UI

  • View build client logs:

    docker compose -f docker/demo/docker-compose.demo.yml logs -f orion_build_client
  • View Orion Server logs:

    docker compose -f docker/demo/docker-compose.demo.yml logs -f orion_server

5. Access the RustFS console (optional)

RustFS object storage provides a web console:

http://localhost:9001/rustfs/console/access-keys

Log in with the following credentials:

  • Access Key: rustfsadmin (or the value of RUSTFS_ACCESS_KEY)
  • Secret Key: rustfsadmin (or the value of RUSTFS_SECRET_KEY)

Service Endpoints

Service URL Description
Mega UI http://app.gitmono.local Web Frontend UI
Mega API http://api.gitmono.local:8000 Mega backend API
Orion Server http://orion.gitmono.local:8004 Orion build server API
Campsite API http://api.gitmono.local:8080 Campsite OAuth/SSO API
PostgreSQL localhost:5432 Database (used by Mega & Orion, mapped to host port 5432 in demo)
MySQL localhost:3306 Database (used by Campsite API, mapped to host port 3306 in demo)
Redis localhost:6379 Cache service (mapped to host port 6379 in demo)
RustFS Console http://localhost:9001 Web console for RustFS object storage
RustFS S3 API http://localhost:9000 S3-compatible endpoint

API Health Check Endpoints

  • Mega API: GET http://api.gitmono.lcoal:8000/api/v1/status
  • Orion Server: GET http://orion.gitmono.local:8004/v2/health
  • Campsite API: GET http://api.gitmono.local:8080/health

FAQ

Port Conflict

Issue: Docker reports the port is already allocated

Solution:

  1. Update the port mapping in the compose file:
    Edit docker/demo/docker-compose.demo.yml and adjust the ports section, e.g.:

    ports:
      - "8001:8000"  # Change host port to 8001
  2. Stop the service occupying the port:

    # Find the process occupying the port (Linux/macOS)
    lsof -i :8000
    # or use netstat (Windows)
    netstat -ano | findstr :8000

Slow First-Time Start

Issue: First run of docker compose up takes a long time

Reason:

  • Images must be pulled from remote registries (may be large)
  • If you are using locally built images, the mega and orion_server services need to be built from source
  • PostgreSQL and MySQL databases need to initialize

Solution:

  • Be patient; the first startup usually takes 5–15 minutes (depending on network speed and hardware)
  • You can view progress in real time with docker compose logs -f
  • Subsequent starts will be much faster (images are cached)

Service Start Failure or Health Check Failure

Issue: Some services remain in unhealthy or restarting state

Troubleshooting Steps:

  1. View service logs:

    docker compose -f docker/demo/docker-compose.demo.yml logs <service_name>
  2. Check dependency services:
    Ensure infrastructure services (PostgreSQL, MySQL, Redis, RustFS) are healthy:

    docker compose -f docker/demo/docker-compose.demo.yml ps
  3. Check environment variables:
    Verify the .env file (if present) has correct settings

  4. Check network connectivity:
    Ensure container-to-container network communication is normal:

    docker network inspect mega-demo-network
  5. Restart a service:

    docker compose -f docker/demo/docker-compose.demo.yml restart <service_name>

Orion Build Client cannot connect to Orion Server

Problem: The orion_build_client container cannot connect to orion_server.

Possible causes:

  • orion_server has not fully started yet
  • Incorrect WebSocket address configuration
  • Network issues

Solution:

  1. Check whether orion_server is healthy:

...

Read more

v0.0.8

30 Sep 08:34
6876fc8

Choose a tag to compare

What's Changed

Read more

v0.0.7

15 Aug 15:35
68ea011

Choose a tag to compare

What's Changed

Full Changelog: v0.0.6...v0.0.7

v0.0.6

04 Aug 14:07
7c22b73

Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v0.0.5...v0.0.6

v0.0.5

22 Jul 03:26
0842b70

Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v0.0.4...v0.0.5

v0.0.4

01 Jul 11:44
1ccbf0c

Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v0.0.3...v0.0.4

v0.0.3

29 Jun 07:05
ceae72a

Choose a tag to compare

What's Changed

  • feat(UI):The editor has added the button function by @Ceron-CSS in #1141
  • refactor(UI): The issue page editing box uses the tiptap component by @Ceron-CSS in #1143
  • feat(UI): add label apis by @benjamin-747 in #1144
  • feat(UI): add support for issue mentions in MentionList component by @yumeowo in #1145
  • feat(libra/diff): support imara_diff v0.2.0 and add the extra param --algorithm of diff command by @erasernoob in #1146
  • Add model in the default folder and refactoring README.md of mercury by @genedna in #1149
  • feat(UI): expand the click range of CodeContent by @yumeowo in #1151
  • feat(UI): rebuild the MR page&add Search component by @liuyangjuncong20202570 in #1153
  • feat: add mr/issue label join query, upadte files-changed api by @benjamin-747 in #1154
  • Changes to the pages related to pull request by @Ceron-CSS in #1161
  • feat: Add tree components to the detail page and files page prelimina… by @larissa-la in #1162
  • fix: Echo message information for the table component and roll back t… by @larissa-la in #1163
  • chore(archived): Remove deprecated code in archived by @benjamin-747 in #1165
  • chore(UI):Remove the title of MR From the url & Modify the position of the merge button by @Ceron-CSS in #1166
  • fix: Fix the tree component echo issue on the file details page by @larissa-la in #1167
  • refactor vault&migration&gemini, add context module by @yyk808 in #1157
  • fix something by @yumeowo in #1168
  • fix(UI): refactor tree api to return all parent tree by @benjamin-747 in #1169
  • fix(UI):use username in conversation and fix clippy in 1.88 by @benjamin-747 in #1171

Full Changelog: v0.0.2...v0.0.3

v0.0.2

19 Jun 14:37
d3d4ddd

Choose a tag to compare

What's Changed

Read more

v0.0.1

29 Apr 13:56
feedd78

Choose a tag to compare

Merge pull request #996 from benjamin-747/main

fix: remove tls server support & comment failed tests