Every developer who has worked on a content-heavy site knows the pain. Your Git repository starts at 50MB. Six months later it is 2GB. Cloning takes forever. Builds crawl. And somewhere in the commit history, there are 47 versions of the same hero image because the marketing team kept tweaking the crop.
Netlify Large Media was built to solve exactly this problem. It integrates Git Large File Storage directly into the Netlify deployment pipeline, so large binary files... images, videos, PDFs, fonts... get stored and served efficiently without bloating your repo.
The Problem with Big Files in Git
Git was designed for source code. Text files. Small diffs. It is brilliant at tracking line-by-line changes in a JavaScript file. It is terrible at handling a 15MB product photo.
Here is why. Git stores every version of every file in its history. Change one pixel in an image and Git stores the entire file again. There is no concept of a diff for binary files. So your repository grows linearly with every change to every asset.
The practical consequences hit fast:
- Clone times explode. New developers joining the project have to download the entire history, including every version of every image ever committed.
- CI/CD slows down. Every build starts with a checkout that pulls all those assets.
- Branch switching lags. Checking out a branch means swapping potentially hundreds of megabytes of binary files.
- GitHub and GitLab enforce size limits. Hit 1GB and you start getting warnings. Hit their hard limits and your pushes fail.
The traditional answer has been "just put assets somewhere else." An S3 bucket. A DAM platform. A shared drive. But that breaks the developer workflow. Now your assets live in one place and your code lives in another, and you need a separate process to keep them in sync.
How Git LFS Changes the Game
Git Large File Storage takes a different approach. Instead of storing the actual binary file in the Git repository, it stores a lightweight pointer file. The actual content lives on a separate LFS server. When you check out a branch, Git LFS transparently downloads the files you need.
The result: your repository stays small. Clones are fast. But from the developer's perspective, the files are just... there. You add them, commit them, and push them like any other file. The LFS integration handles the rest.
Netlify Large Media builds on this by making the LFS server part of your deployment pipeline. Assets tracked by LFS get served through Netlify's CDN with automatic image transformation built in. That last part is important... it means you can store one high-resolution source image and let Netlify generate the sizes and formats you need on the fly.
Setting It Up
The setup process is straightforward if you are already on Netlify. The high-level steps:
- Install Git LFS locally. Most package managers have it.
brew install git-lfson macOS,apt install git-lfson Ubuntu. - Initialize LFS in your repo. Run
git lfs installin your project directory. - Track file patterns. Tell LFS which files to manage:
git lfs track "*.jpg" "*.png" "*.mp4" "*.pdf". This creates a.gitattributesfile that Git uses to know which files should go through LFS. - Install the Netlify Large Media plugin. The Netlify CLI handles this:
netlify plugins:install netlify-lm-pluginfollowed bynetlify lm:setup. - Commit and push. LFS pointer files go into Git. The actual assets go to Netlify's LFS storage.
One thing to watch out for: if you have existing large files in your repository history, you will want to migrate them to LFS using git lfs migrate. Otherwise they stay in your Git history and you do not get the size benefits for those files.
Image Transformation on the Fly
This is where Netlify Large Media gets genuinely useful beyond just storage. Because assets are served through Netlify's CDN, you get URL-based image transformations for free.
Want a 400px wide thumbnail? Append ?nf_resize=fit&w=400 to the image URL. Need a square crop? ?nf_resize=smartcrop&w=300&h=300. The transformations happen at the CDN edge, so they are fast, and results are cached.
This means your content editors can upload one high-resolution source image and you can generate every size variant your responsive design needs without a build step, without an image processing pipeline, and without storing multiple versions of the same asset.
For a typical marketing site with 50-100 images, this eliminates an entire category of build complexity. No more sharp, imagemin, or custom webpack loaders generating responsive image sets at build time.
When This Approach Makes Sense
Netlify Large Media is not the right fit for every project. Here is where it shines and where you might want something different:
| Good Fit | Better Alternatives |
|---|---|
| Marketing sites with moderate asset counts (under 1,000 images) | E-commerce with 10,000+ product images (use a dedicated DAM) |
| Developer-managed assets where Git workflow matters | Non-technical teams who need a visual interface for uploads |
| Projects already deployed on Netlify | Multi-platform deployments where CDN lock-in is a concern |
| Static sites and JAMstack architectures | Dynamic applications with user-uploaded content |
The sweet spot is a developer-driven team building a content site on Netlify where assets change occasionally and the team wants to keep everything in Git. If your content editors are uploading hundreds of images weekly through a CMS, a dedicated media pipeline (Cloudinary, imgix, or your CMS's built-in asset management) is probably the better call.
The Bigger Picture: Asset Strategy Matters
The reason we bring up Netlify Large Media is not because it is the only solution. It is because it represents a broader principle that most teams overlook until it bites them: you need an asset strategy from day one.
We see this pattern constantly. A team launches a site. Assets go into the repo because it is easy. Six months later, builds take 8 minutes. A year later, someone commits a 200MB video and everything grinds to a halt. Then it is a fire drill to migrate assets somewhere else while production is running.
Whether you use Netlify Large Media, a headless CMS with built-in asset management, a dedicated CDN like Cloudinary, or an object storage service like S3... the important thing is making that decision early and sticking with it.
A good asset strategy answers three questions:
- Where do source files live? Git, CMS, DAM, or cloud storage?
- How are they transformed? Build-time processing, on-the-fly CDN transforms, or pre-generated variants?
- How are they served? Same-origin, CDN subdomain, or third-party service?
Get those three answers right and your asset pipeline will scale gracefully. Get them wrong... or do not answer them at all... and you will spend a disproportionate amount of time fighting your build system instead of building features.
Need help figuring out the right asset architecture for your project? Let's work through it together.