Even with a 30GB monolithic repository, the development environment doesn't slow down — How Shopify powers "World"

Series "Development Infrastructure Architecture in the AI-First Era" Part 2 (of 3)

In Part 1, I wrote that Shopify "didn't split things up, but rather used technology to overcome the pain." They chose to consolidate all company code into a single "World" and build their own infrastructure to support it, even if it meant CI swelling tenfold. Part 2 delves into the specifics of that "technology."

Before that, let's acknowledge the prevailing sentiment of the time. Monorepos were long synonymous with "outdated monoliths." For the past decade, modern design has been all about microservices: breaking services into smaller pieces, separating repositories, and making teams independent. This was the trend where startups proudly pitched, "We use microservices." Reverting everything to a single repository seemed like a regression.

That pendulum is now swinging in the opposite direction. The trigger, as we saw in Part 1, was AI. The boundaries we'd created to align with human perspectives became barriers for AI. That's why monorepos, as a "unit of development," are making a comeback. However, it's not a return to the old monoliths as they were. It requires technical backing to make it work. This is where the main topic begins.

Monorepos have always presented persistent challenges: Git becoming slow, CI collapsing, and tangled dependencies. Shopify's "World" exceeds 30GB of code alone and is touched by tens of thousands of people. By conventional wisdom, it should have failed immediately at this scale. So how does it work? The key lies in an evolved way of using Git and a somewhat unusual package manager called Nix (Shopify's own explanation is "What Is Nix").

01 Git will cry for help first if you simply use a monorepo

The first hurdle in monorepo adoption is usually Git itself.

Nix has a mechanism called Flakes that ensures build reproducibility. However, this is designed to copy the entire source tree to a local store (/nix/store) every time it's evaluated. For a repository of a few tens of MB, this isn't noticeable. But when done with a 30GB "World," disk I/O dries up, and evaluation speed drops to an impractical level. So, using raw tools on a giant repository breaks them.

CI was the same. As mentioned in Part 1, integrating all repositories increased CI execution scale tenfold overnight. They had to rebuild the queue that processed merges and re-architect the build cache itself into an in-house product. The common wisdom that "monorepos are heavy" proved true, at least on day one. The root cause is the same as the pain Cookpad faced, as mentioned in Part 1, which they "escaped" by splitting things up. The difference is that Shopify didn't escape it but instead rebuilt its tools.

02 Tectonix - Reading Git directly without copying everything

That tool is Tectonix. It's a build system custom-built by Shopify to power the "World," combining Git's sparse-checkout, NixOS's module system, and custom extensions. While the name might sound complex, it does one thing: don't copy everything locally.

Developers use sparse-checkout to pull only the files relevant to their work locally. There's no need for all 30GB. Only the necessary zones (units of sub-projects) are kept locally.

The challenge is how to correctly handle dependencies with code that isn't locally present. This was the core of Tectonix. Shopify forked the Nix evaluation engine itself (internally called tecnix) and preemptively introduced a mechanism called lazy-tree. This concept involves reading source directly from Git's object database, without relying on files on the physical disk. Even areas not checked out locally can have their dependency graph accurately constructed by referencing Git's hash index. The waste of physically duplicating the entire repository is completely eliminated.

An analogy to a library is helpful. Instead of bringing all the books home, you only borrow the ones you're currently reading. Yet, by looking at the catalog (Git's hashes), you can accurately trace relationships even with books you haven't borrowed. What Tectonix does is similar to this.

Developers directly interact only with small declaration files called zone.nix located in each zone. They describe "what this service needs and how it should be built," and the complex evaluation logic is handled by the underlying plumbing. Additionally, at the lower layers of CI, static analysis by Semgrep and policy enforcement by OPA (Open Policy Agent) are in place, creating a defense line to prevent configuration errors that could affect millions of merchants from being merged.

03 "Same result no matter who does it" enables autonomous AI execution

Shopify's insistence on Nix was for reproducibility.

Local, CI, and production containers. These three environments are reproduced exactly, without a single discrepancy. For humans, the futile bug of "it works on my machine but crashes in production" disappears. For AI, it has an even more critical meaning: inference noise caused by environmental differences vanishes, and build errors encountered by AI are narrowed down to "pure code errors" only. Agents can run tests themselves and trust the results to take the next action precisely because of this reproducibility.

The design of Aquifer, the agent infrastructure that powers River, also rests upon this reproducibility. It's divided into three layers: Session, which stores conversation and decision history (a Postgres append-only log that persists even if it crashes); a disposable Harness, which handles thinking; and a sandboxed Sandbox, which actually builds and executes code in an isolated environment. The Sandbox is a disposable environment hardened with Nix and completely separated from the Harness. Even if an agent accidentally runs a destructive command, the extent of the damage (blast radius) is confined to that sandbox. It's a physical partition for safely "letting AI take action."

04 Keeping deployments separate, unifying only development

Let me clear up one misconception. Just because "World" is a single repository doesn't mean that production has become a monolithic application.

Shopify still deploys to production as microservices, as before. What has been consolidated is the "unit of development and management," not the "unit of deployment and failure." To put it back in the terms of Part 1, this is a two-pronged approach: maintaining the fault isolation gained by splitting services while resolving the context fragmentation that was troubling AI. Development is unified, but deployments remain separate. This is becoming one of the stable points for large-scale development in 2026.

Google's Bazel and Meta's Buck2 have also tackled the same challenges. However, to guarantee build correctness, they effectively "exclude" language-standard package management systems like npm and Cargo, demanding a rewrite to their proprietary build rules. This requires dedicated teams and significant migration friction. In contrast, Tectonix embraces these existing tools with Nix, allowing developers to avoid discarding their familiar tools. It directly confronts Git's physical limitations with lazy-tree while retaining language-standard tools. This lack of forced change is a hallmark of this approach.

Finally, in 2026, Shopify acquired Garnix, a Nix-based CI system. Its core technology, call-by-hash, builds the production environment uniquely from the hash of a merged commit, enabling instant deployments without unnecessary rebuilds and atomic rollbacks. The aim is to permeate the entire process from build to deployment with a single hash.

Flagship's View - Reproducibility works even at non-Shopify scales

Up to this point, we've discussed some rather heavy-duty setups. Frankly, most of this isn't something we'd implement ourselves.

Recall the line I drew in Part 1. If a human is merely issuing commands to AI locally, sparse-checkout and lazy-tree aren't necessary. Having multiple repositories in a client's folder and documenting the decision-making process is sufficient. An investment on the scale of Tectonix only pays off at the phase where tens of thousands of people are involved, and autonomous agents are routinely running production code. This level of complexity is only justified at that scale.

On the other hand, the philosophy to emulate is clear: reproducibility. We've intentionally broken systems before production with our load testing tool, Mockingbird, and for migration projects, we've meticulously documented procedures to ensure that anyone performing them arrives at the same result. An unreproducible environment is dangerous for both humans and AI. This realization perfectly aligns with Shopify's reason for adhering to Nix — "getting the same results no matter where it runs." Therefore, what we actually set up is not a full Tectonix, but rather "reproducible environments and clear documentation." That's where the investment and effect align best.

Limitations and Operational Notes

Nix is not a silver bullet. Shopify itself attempted to introduce Nix into its development environment around 2019 but was thwarted by its high learning curve. Its current success came only after tools like devenv, which can declaratively configure environments, matured and the conditions were right.

Gritty adaptations were also unavoidable. For instance, issues arose where Nix's read-only file system clashed with existing tools that assumed write access, causing Cloudflare's tunnel tool to crash on startup (EROFS errors). Shopify resolved this by pinning versions and redirecting write locations, but it was the accumulation of these individual fixes that brought Tectonix to a practical level. Behind the flashy architectural diagrams lies a vast amount of unglamorous adaptation work. Misunderstanding this will result in tools that are implemented but don't function.

Summary

The conventional wisdom that "monorepos are heavy" has been overcome to the point where it can be crushed by evolved Git (sparse-checkout and lazy-tree) and Nix, which returns the same results everywhere. However, this is only possible with a corresponding investment in infrastructure. Development unified, deployments separated — large-scale development is now settling into this form.

So, who exactly benefits from this infrastructure, so carefully crafted for AI? In the final Part 3, we will delve into how the environment prepared for AI also accelerates human development — the shift from DX to AX (Agent Experience).

References and Sources

• Under the River (Shopify Engineering, 2026)
• What Is Nix (Shopify Engineering)
• Tectonix: The bedrock of Shopify's Monorepo (SCALE 23x)
• Planet Nix 2026: Tectonix - Lecture Recording (YouTube)
• Shopify/tecnix (GitHub)
• Nix-based development environments at Shopify (reprise) (NixCon 2025)
• garnix is joining Shopify (garnix.io)
• Small Models, Massive Wins: Shopify's New AI Formula (VentureBeat)

The information in this article is current as of July 2026. The implementation details of Tectonix, tecnix, lazy-tree, and zone.nix are reference information based on Shopify's presentations (SCALE 23x / Planet Nix 2026) and public repositories, and may change in the future.