Shrinking the Monorepo to Improve Development Speed

As Dropbox's server monorepo grew to 87GB, initial clones took over an hour, and CI and sync systems kept paying the same cost repeatedly. When GitHub's 100GB limit eventually became a real risk, the team found that the problem wasn't the amount of storage but how Git delta compression worked.

The cause was the i18n file path structure. By default, Git groups similar files based on the last 16 characters of the path, but in Dropbox's paths the language code came earlier, so deltas were often computed between files in different languages, causing translation updates to produce excessively large pack files.

Locally, repacking with the --path-walk experimental flag reduced the repository from 84GB → 20GB, but this approach was incompatible with GitHub's server-side optimizations. Instead, working with GitHub Support, they performed the repack on the server with more aggressive window/depth settings, achieving the same level of compression over about 9 hours.

The rollout was treated like a production infrastructure change. It was first validated on a test mirror, monitoring fetch latency, push success rate, and API latency, and then gradually applied to replicas one per day over 1 week. In the end, the repository shrank from 87GB → 20GB, and clone time dropped from over 1 hour to under 15 minutes.

This effort also left behind a system to prevent recurrence.

• Adjusted the i18n workflow to better align with Git's packing method, reducing pathological delta pairing.
• Created a recurring stats job to track repository size, growth rate, fresh clone time, and storage distribution.
• Established standards for managing repo health like a service, enabling early detection of abnormal growth.