For reasons that still escape me, Heroku has a 1GB limit on Git repository sizes. Yeah, I know. In 2025, 1GB is practically a rounding error.

Anyways, we hit that limit. Hard. And our entire company’s development process ground to a halt.

I had to drop everything to investigate because no one could ship or deploy anything until it was resolved. The immediate fire was put out with a repository reset, which got things moving again. But as with any scary DevOps issue, fixing the immediate problem is only half the battle. A root cause analysis was essential to prevent it from happening again.

The Investigation

My first hunch was the usual suspect. I figured I’d search back through the Git history and find that at some point, a teammate had accidentally checked in a large data file or, the classic blunder, forgot to gitignore the node_modules directory.

I ran a script to show an ordered list of all the blobs in the repo. A few large images stood out, but nothing that would account for that much bloat. I kept scrolling down the list, and a pattern started to emerge.

Some background: this is an old application with a complex front end. We’re talking 10+ years of complex, real-time whiteboarding functionality powered by a frankenstein of front-end framework glue. It has a ton of dependencies, which we’ve kept reasonably updated over the years. We were ignoring node_modules, so that couldn’t be the issue… right?

Wrong

You still need to keep track of dependency versions in your good old package-lock.json file. And as I scrolled down that list of repo blobs, that’s what I started to see.

Hundreds and hundreds of package-lock.json diffs.

They varied in size, from just over 100 KB to more than 2 MB each.

The root cause of our repo bloat—the reason our entire development pipeline seized up—was almost 1GB of compressed package-lock.json diffs.

You really can’t make this stuff up.