Holding the Line on a Gatsby Site in 2026

I’ve been running my portfolio on Gatsby since the framework felt like the future. Three years after Netlify bought it, I keep wondering how much longer I can maintain it.

Last week I tried to upgrade a dependency on my portfolio site and ended up an hour deep in a thread of unresolved GitHub issues from 2024. The plugin I was trying to update hadn’t shipped a release in over two years. The workaround in the thread pointed at a fork from a stranger that “mostly works.” I closed the tab, reverted my package.json, and went to bed.

The site is still Gatsby. It’s still running. And I’m starting to feel like the last guy at the party who hasn’t called a cab yet.

When Gatsby Felt Like the Answer

Rewind to 2019. I was rebuilding my personal site for what felt like the fifth time, and Gatsby genuinely felt like a leap forward. React for the component model, GraphQL as a unified data layer, image optimization that actually worked out of the box, and a plugin ecosystem that could pull content from anywhere. The first time I saw a Gatsby site light up on Lighthouse with a perfect score, I was sold.

That same year, Gatsby raised a $15M Series A and announced that roughly 1% of the top 10,000 websites were running on the platform. IBM, PayPal, Airbnb. The plugin marketplace exploded. Component shadowing let you fork a theme without forking a repo. gatsby-image was, no exaggeration, one of the best image components on the web.

It worked. For a long stretch, it really worked.

Watching the Vibes Shift

The first cracks weren’t technical. Build times had been a grumble for years; that wasn’t new. What changed around 2021 and 2022 was that the alternatives stopped being theoretical. Next.js had pulled clearly ahead. Vite was starting a dev server in under a second while my Gatsby site took 30 seconds just to acknowledge I existed. Astro showed up and quietly did everything Gatsby’s static side did, faster, with a fraction of the conceptual overhead.

I remember reading a Reddit thread in 2022 titled “Is Gatsby dying?” and feeling defensive about it. Like, no, my site is fine, the plugin I use just got an update last month, the community is still active. I was talking myself into it more than the post talked me out of it.

Then in February 2023, Netlify acquired Gatsby Inc. The announcement was full of the right words: composable architectures, stewardship, open source commitment. Within months, most of the core team was gone. LekoArts left. The release cadence cracked. Gatsby Cloud got sunset and folded into Netlify’s hosting, which broke a real workflow for a lot of people. The plugin ecosystem; once the framework’s biggest moat; started to calcify.

You can argue about who was responsible. The story I keep coming back to is simpler: Gatsby tried to be a static site generator AND a competitor to Next.js AND a hosting company, and the third thing ate the first two.

What It’s Like Maintaining a Gatsby Site in 2026

I’ll give the team credit: Gatsby isn’t dead in the literal sense. React 19 support landed. Node 22 is officially supported. The releases page on GitHub still has activity. Robin Wieruch’s recent retrospective calls it “maintenance mode at best,” and that feels right to me. The lights are on. Nobody’s racing to add new features.

The day to day is fine, until it isn’t. The pattern looks like this:

• Node ships a new LTS. Something in the Gatsby toolchain breaks in a non-obvious way.
• A plugin I depend on hasn’t been touched in two years. The plugin it depends on hasn’t been touched in three.
• I add a resolution to package.json, get the build green, and move on with the quiet awareness that this is a load-bearing rubber band.

It’s not painful enough on any given day to migrate. That’s actually the trap. Each individual workaround is small. Cumulatively, I’m spending real time on infrastructure work for a site that should be one of the lowest-maintenance things I own.

# the kind of command I now run before I trust anything
rm -rf node_modules .cache public
nvm use 20
npm ci
npm run build

# the kind of command I now run before I trust anything
rm -rf node_modules .cache public
nvm use 20
npm ci
npm run build

That cold-cache build is the canary. When it goes green on a fresh clone, I sleep fine. When it doesn’t, I’m back in the threads.

Why I Haven’t Left Yet

Honest answer: inertia, plus a stubborn affection. The site works. The content is right. The build is green this week. Every hour I spend rewriting the frontend is an hour I’m not spending on the projects I actually want to ship.

There’s also a thing nobody talks about when they recommend migrations: the depth of the customization. My Gatsby setup has accumulated years of MDX wiring, custom GraphQL fragments, image handling tuned for specific layouts, and a handful of plugins I patched myself. Rebuilding all of that on Astro or Next is not a weekend project. It’s a real chunk of work, and the payoff is “the same site, but I can sleep at night when Node releases.”

Still, I can feel the math shifting. The cost of staying gets a little higher every quarter. The cost of leaving stays roughly the same.

Where I Think I’m Headed

If I had to bet on what I’ll be on a year from now, the shortlist is short:

• Astro for the content side. Content collections solve the build-time-blog problem the way Gatsby’s GraphQL layer tried to. Faster, simpler, and the React story is good enough to bring most of my components over.
• Next.js if I want to lean into more app-like sections. Server components, file-based routing I already know, an actually maintained image component.

I keep landing on Astro for this specific site. It’s the closest thing to a Gatsby that’s still being loved on. The mental model is small. The output is static HTML. The dev server starts before my coffee finishes pouring.

The Lesson I Keep Coming Back To

I picked Gatsby in 2019 because it was the best tool for the job. That was a good decision at the time, and I’d make it again. The thing I didn’t appreciate well enough was how much of “is this the right framework” lives in the maintainership and the community around it, not the framework itself. A static site generator can ship great code in 2019 and still leave you patching dependency trees in 2026 because the people who knew how to evolve it got laid off.

It’s not a knock on Kyle Mathews or the original team. They built something genuinely good and they were ahead of the pack for years. It’s a reminder that I’m not really betting on a tool when I pick a framework. I’m betting on a community deciding to stick around. Sometimes they don’t.

If you’re running Gatsby today, I don’t think you need to panic. Nothing is on fire. But I’d start sketching a migration plan, even if you don’t pull the trigger this year. The exit ramp is easier to walk down when you’ve already mapped it.

If you’ve already migrated off, I’d genuinely love to hear what you moved to and how the cutover felt. I’ll probably need that war story before the year is out.