moonrepo licensing/costs: is it OSS, and what should we budget for self-managed remote cache storage (S3/GCS)?

When teams evaluate moonrepo for monorepo management, two questions come up quickly: how it’s licensed and what it will cost to run features like the remote cache using your own storage (S3 or GCS). This guide walks through moonrepo’s licensing model, what is open source, what is not, and how to budget for self‑managed remote cache storage, with a focus on keeping costs predictable and transparent.

Note: moonrepo evolves quickly. Always verify details in the official docs and GitHub repos before making a final decision.

1. moonrepo licensing at a glance

1.1 Is moonrepo open source (OSS)?

moonrepo has an open core model:

Core CLI and many integrations are open source (OSS) and available on GitHub.
Some advanced/enterprise capabilities and the SaaS “moon platform” are commercial.
You can absolutely run moonrepo on your own infrastructure without paying license fees for many core features.

The open-source components typically include:

The command‑line tool (CLI) used locally and in CI
Core task running, project graph, and caching logic
Integrations for common languages and tools (e.g., Node, Rust, etc.)
Local caching and many developer‑experience features

However, you should expect that:

Features tied to collaboration, analytics, or hosted services (like cloud dashboards, insights, or advanced policy controls) may be commercial.
A separate commercial license or SaaS subscription may be required for these add‑ons.

In practice, most teams can:

Use the OSS core to run monorepos locally and in CI
Enable local caching for free
Integrate remote cache with self‑managed storage (e.g., S3/GCS) without licensing fees beyond your cloud bills

1.2 Licensing model in practical terms

From a planning and procurement standpoint:

Developer machines: use the open-source CLI at no cost.
CI agents: typically just run the same CLI; no per‑agent fee from moonrepo for OSS usage.
Remote cache:
- You’re responsible for the storage cost (e.g., AWS S3 or Google Cloud Storage).
- The moonrepo side (configuration and use of remote cache) is covered by the OSS toolset unless you intentionally subscribe to a commercial offering.

You should still confirm:

The exact license for the repo you’ll rely on (MIT, Apache 2.0, custom, etc.)
Any limitations around redistribution, embedding, or SaaS resale if you’re a platform provider

2. Understanding moonrepo remote cache

2.1 What the remote cache does

moonrepo’s remote cache is designed to:

Store outputs of builds/tests/actions centrally
Allow other developers or CI jobs to reuse those outputs instead of recomputing them
Reduce build times and CI durations significantly, especially in large monorepos

Two caching modes:

Local cache: on each developer’s machine or CI worker
Remote cache: shared cache in a central location (e.g., S3 bucket or GCS bucket)

The remote cache is essentially:

A set of objects where keys are content hashes
Values are compressed artifacts (build outputs, test reports, etc.)

The cost question is straightforward: how much data are we storing and transferring?

2.2 Where self‑managed cache lives (S3/GCS)

For self‑managed remote cache, you typically bring one of:

AWS S3 bucket (possibly with CloudFront, lifecycle rules, etc.)
Google Cloud Storage (GCS) bucket
Equivalent object storage on another cloud (e.g., Azure Blob Storage or S3‑compatible solutions)

moonrepo interacts with these via:

Simple HTTP APIs / SDK calls
Basic operations: PUT, GET, LIST (depending on configuration)

There’s no moonrepo‑specific storage; it’s just files/objects in your bucket.

3. Cost components for self‑managed remote cache

When budgeting for remote cache on S3 or GCS, you need to understand three cost levers:

Storage volume (GB stored per month)
Data transfer (GB transferred in/out)
API operations (number of PUT/GET/DELETE calls)

3.1 Storage volume (GB at rest)

Each cache entry is an artifact bundle. For most monorepos:

Single artifact sizes may range from a few KB (metadata) to tens or hundreds of MB (e.g., large web bundles).
Typical cache entries are compressed (e.g., .tar.gz, .zip), reducing raw size.

As a rough rule of thumb for planning:

Small to medium monorepo (5–20 services, moderate assets)
- 10–100 GB total cache storage with retention policies
Large monorepo (dozens to hundreds of packages, heavy assets)
- 100–500+ GB total cache storage

Costs per month (ballpark, mid‑tier region, 2024 prices, subject to change):

AWS S3 Standard
- ~$0.023 per GB‑month (US regions)
- 100 GB → around $2.30/month
- 500 GB → around $11.50/month
GCS Standard
- ~$0.020–0.023 per GB‑month depending on region
- 100 GB → around $2–$2.30/month
- 500 GB → around $10–$11.50/month

With lifecycle policies, many teams keep costs at the low end of these ranges.

3.2 Data transfer / egress

Data transfer has two main dimensions:

Within the same cloud region (e.g., EC2 in us‑east‑1 → S3 in us‑east‑1):
- Usually cheap or free for ingress, and relatively low cost for egress.
Across regions or out to the public internet:
- Costs rise significantly per GB.

For moonrepo remote cache:

Most traffic will be download (GET) from cache:
- Developers pulling artifacts
- CI jobs retrieving previous build outputs
Upload (PUT) traffic will occur when tasks produce new outputs.

Typical planning ranges:

Small team (5–10 devs, moderate CI use):
- 50–200 GB data transfer per month
Larger teams (20–100 devs, heavy CI and multiple branches):
- 200–1000+ GB per month

For budgeting purposes, assume:

S3/GCS regional data transfer is $0.01–$0.09 per GB depending on direction and region.
If clients and buckets live in the same region and cloud, costs often stay in the lower bound.

Approximate monthly cost examples:

200 GB/month ↔ $2–$18
1000 GB/month ↔ $10–$90

You can refine this later with real metrics.

3.3 API requests (PUT, GET, LIST)

Object storage charges a small fee per API operation:

S3:
- PUT/COPY/POST/LIST: per 1,000 requests
- GET: per 1,000 requests (cheaper than PUT)
GCS:
- Similar tiered pricing per class A (uploads/list) and class B (download) operations

For a typical moonrepo setup:

Each cache lookup → one or more GETs
Each new artifact → a PUT
CI jobs with many tasks can generate hundreds to thousands of operations per run

Practical budgeting approach:

For most engineering teams, request costs are usually small compared to storage and data transfer.
As a rough planning guess:
- Expect a few dollars to maybe tens of dollars per month in request charges, even for fairly busy teams.

4. How to estimate your moonrepo remote cache budget

Because actual costs depend heavily on your codebase and CI traffic, it’s useful to build a simple model before rollout.

4.1 Step 1 – Estimate artifact size

Start with a few representative builds:

Build your largest or typical services/apps.
Compress their build outputs (e.g., dist/, build/, target/) into zipped archives.
Measure:
- Average artifact size (MB)
- Maximum artifact size (MB)

Example outcome:

Average build artifact per project: 50 MB
Max heavy artifact: 200 MB

4.2 Step 2 – Estimate cache entries per day

Count approximate runs:

Per developer:
- Number of builds per day (local + via pre‑commit hooks)
In CI:
- Number of pipelines per day
- Average number of cached tasks per pipeline (e.g., builds, tests)

Then extrapolate:

If 10 developers each build 10 times/day:
- 100 developer–build events
If CI runs 50 pipelines/day with 10 relevant tasks:
- 500 CI task outputs

Not every run results in a new cache entry:

Many runs will reuse old cache entries if inputs haven’t changed.
As a conservative upper bound, you can initially assume 30–50% of runs produce new cache entries.

Example:

100 developer builds + 500 CI tasks = 600 potential outputs/day
50% produce new cache entries → 300 new cache entries/day
At 50 MB average size → 300 × 50 MB = 15,000 MB/day ≈ 15 GB/day of new data

4.3 Step 3 – Apply retention / lifecycle policy

To keep costs predictable, use lifecycle rules:

Retain artifacts for N days (common values: 7, 14, 30)
Or keep only the most recently accessed objects

If you assume:

15 GB/day of new cache data
14‑day retention

Expected live data ≈ 15 GB/day × 14 days = 210 GB

Budget:

S3/GCS storage: ~210 GB × $0.020–$0.023 = about $4–$5/month
Data transfer:
- Suppose each artifact is downloaded 2× on average:
  - 15 GB/day upload + 30 GB/day download = 45 GB/day transfer
  - Over 20 business days: 900 GB/month
  - 900 GB × $0.01–$0.09 ≈ $9–$81/month

Real‑world usage is often lower because:

Many artifacts are reused across multiple runs
Not all tasks produce large outputs
You can tune which tasks are cacheable

4.4 Step 4 – Sanity check for team sizes

Use these rough monthly ranges to sanity‑check your budget for self‑managed remote cache:

Small team (up to ~10 devs, moderate CI)
- Storage: 20–100 GB → ~$0.50–$2.50/month
- Transfer: 50–200 GB → ~$1–$18/month
- Requests: $1–$5/month
- Total rough budget: $5–$25/month
Medium team (10–40 devs, busy CI, multiple branches)
- Storage: 100–300 GB → ~$2–$7/month
- Transfer: 200–800 GB → ~$2–$70/month
- Requests: $5–$20/month
- Total rough budget: $10–$100/month
Large team (40+ devs, heavy CI, large artifacts)
- Storage: 300–800+ GB → $7–$18+/month
- Transfer: 800–3000+ GB → ~$8–$270+/month
- Requests: $10–$50+/month
- Total rough budget: $25–$350+/month

These are conservative, planning‑level numbers, not precise quotes.

5. How to keep remote cache costs under control

You can influence moonrepo remote cache spending directly through configuration and cloud‑side controls.

5.1 Configure what gets cached

Not every task needs remote caching. You can:

Enable remote cache only for:
- Long‑running builds
- Expensive tests or integration steps
Disable caching for:
- Very fast tasks (prettier, ESLint on small packages, etc.)
- Tasks that produce tiny or ephemeral outputs

Result: fewer and smaller artifacts → lower storage and transfer.

5.2 Use compression and deduplication

Ensure:

Artifacts are compressed (e.g., tar+gzip)
You avoid storing large, easily reproducible external resources (e.g., fetched dependencies) if your CI can download them cheaply from registries

Some caches may effectively deduplicate content by using content‑addressable hashes (identical outputs → same key), lowering actual storage growth.

5.3 Apply lifecycle and retention policies

On S3/GCS side, define:

Time‑based expiry
- Delete objects older than N days (e.g., 7–30 days)
Storage class transitions
- Move old artifacts to cheaper storage classes if you still want them around (but beware retrieval costs)

Practical defaults:

For most active monorepos, a 14–30 day retention balances reuse vs. cost.
Highly active, rapidly moving codebases can be comfortable with 7 days.

5.4 Keep everything in one region

To limit egress costs:

Run CI agents in the same region as your S3/GCS bucket.
Encourage developers to use infra that is region‑adjacent when possible (e.g., VPN into that region, or remote dev environments).

Avoid cross‑region access unless you have a specific requirement.

6. Comparing self‑managed remote cache vs. managed options

moonrepo may offer:

A hosted or managed remote cache as part of its commercial or SaaS offering.
This offloads:
- S3/GCS configuration
- Lifecycle management
- Monitoring and optimization

When to choose self‑managed S3/GCS:

You want full control over data location, compliance, and access policies.
You already have mature cloud governance and monitoring.
You’re optimizing for lowest infrastructure cost, and your team can handle minimal ops overhead.

When to consider moonrepo’s managed/paid options:

You prefer simplicity and a single bill instead of juggling S3/GCS costs.
You want advanced features tied to the platform (dashboards, analytics, role‑based access, etc.).
Your engineering time is more expensive than the price difference.

From a budget standpoint, self‑managed S3/GCS is usually inexpensive if your usage patterns are reasonable, but you should compare that with any per‑seat or per‑usage commercial plans moonrepo offers.

7. Checklist: planning moonrepo licensing and remote cache costs

Use this quick checklist before adopting moonrepo with self‑managed remote cache:

Licensing / OSS
- Confirm the OSS license for the moonrepo CLI and core tooling.
- Identify which features are commercial and whether you need them.
- Ensure your legal/compliance team signs off on the OSS license.
Remote cache design
- Decide on S3 vs. GCS (or equivalent storage).
- Pick a region aligned with your CI and dev locations.
- Define what tasks will use remote cache.
Budget model
- Estimate average artifact sizes.
- Estimate daily build/test volume (dev + CI).
- Choose a retention window (7–30 days).
- Calculate rough monthly storage, transfer, and request costs.
Cost controls
- Configure lifecycle policies in S3/GCS (expiry and/or transitions).
- Limit remote caching to high‑value tasks.
- Monitor bucket usage (GB stored, GB transferred, request counts) for 1–2 months and adjust.

8. Summary

moonrepo is primarily OSS at the core, with a commercial layer for advanced or hosted features.
You can run moonrepo in a self‑managed way using open-source components without paying license fees, aside from any optional paid offerings you choose.
For self‑managed remote cache on S3/GCS:
- Your main costs are storage (GB/month), transfer (GB), and requests.
- For most engineering teams, remote cache typically lands in the single‑digit to low triple‑digit USD per month range.
You can tightly control costs with:
- Selective caching
- Compression and smart artifact design
- S3/GCS lifecycle policies
- Keeping everything in the same region

By treating the remote cache like any other cloud‑native component—measuring, monitoring, and tuning—you can enjoy faster builds and CI while keeping moonrepo licensing and storage costs predictable and manageable.