Gatsby Maintenance & Rescue

Not every Gatsby site needs to be migrated this year. Plenty of teams have a Gatsby 4 or 5 site that still does its job, and the right move is to keep it building, keep it secure, and host it somewhere reliable now that Gatsby Cloud is gone. StaticCraft offers maintenance and rescue for legacy Gatsby sites, with a clear path to migration whenever you are ready.

Rescue: when the build is already broken

The most common call we get is "the site will not build any more and nobody changed anything." The usual culprits:

• Node version drift. A CI image or host moved to a newer Node LTS and gatsby build fails on native modules or deprecated APIs. We pin the Node version in .nvmrc, engines, and the host config, and test the upgrade path to the newest Node that Gatsby 5 tolerates.
• sharp and other native modules. Image processing breaks after a platform or libvips change. We align sharp across Gatsby's image plugins and your lockfile so there is exactly one version being built.
• Lockfile loss. Someone deleted package-lock.json or yarn.lock and the next install pulled incompatible transitive dependencies. We restore a known-good lockfile and put a lockfile check in CI.
• Dead plugins. A plugin that depended on an API that no longer exists (Gatsby Cloud preview, a sunset SaaS endpoint). We remove or replace it.
• Gatsby Cloud leftovers. gatsby-plugin-gatsby-cloud, preview webhooks, and gatsby-cloud scripts that now fail or hang.

Rescue work is scoped as a short fixed engagement: get the build green, document what changed, hand it back.

Maintenance: keeping a Gatsby site healthy

For sites you intend to keep running, we offer an ongoing retainer covering:

• Dependency and security patching. Monthly review of npm audit output, with patches applied where a fix exists and a written risk note where it does not (maintenance-mode plugins will not always get one).
• Node compatibility. Tested upgrades when a Node LTS line reaches end of life, so you are never stuck on an unsupported runtime.
• Build monitoring. Alerting when builds fail or build time regresses, with a root-cause write-up.
• Uptime and performance monitoring. Synthetic checks and Core Web Vitals tracking for the pages that matter.
• Content and small feature changes. Template tweaks, new pages, and plugin configuration, inside the retainer hours.

Hosting after Gatsby Cloud

Gatsby Cloud shut down in September 2023. Gatsby 5 now deploys through adapters, and your options depend on which Gatsby features you use:

• Netlify with gatsby-adapter-netlify is the closest drop-in: DSG and SSR routes, redirects, and headers all work.
• Vercel has first-party Gatsby support and is a natural fit if you plan to migrate to Next.js later.
• Cloudflare Pages / Workers suits fully static Gatsby sites and is hard to beat on edge delivery and cost.
• AWS Amplify or S3 + CloudFront for teams already on AWS; fully static builds only for S3 + CloudFront.
• GitHub Pages for small, fully static sites with no server-side features.

We move your site, wire up CI builds without Gatsby Cloud, and keep the old host warm until the new one is verified.

Retainer tiers

• Stabilize — a one-time rescue plus a 30-day warranty on the build.
• Maintain — monthly patching, build and uptime monitoring, and a block of hours for changes.
• Maintain and plan — everything in Maintain plus a migration assessment and a standing plan, so when you decide to move there is no discovery phase.

Numbers depend on site size and hosting; we quote after a short review of your repository.

Stabilize now, migrate later

Maintenance is not a way of avoiding the decision about Gatsby's future; it is a way of making that decision on your schedule. Every retainer includes a yearly written recommendation on whether it is time to migrate, and when it is, our Gatsby migration service picks up with the assessment already done.

If your Gatsby site is broken, slow, or simply unowned, contact us and we will take a look.