Gatsby Cloud shut down in September 2023, about seven months after Netlify acquired Gatsby Inc. If your site still has gatsby-plugin-gatsby-cloud in its config or a dead preview webhook in your CMS, you are one of many. This guide covers where a Gatsby site can live in 2026, which Gatsby features each host supports, and what it is likely to cost, so you can pick a host without re-learning it the hard way.
First: what does your site actually use?
Gatsby 5 has three rendering modes, and the host you need depends on which ones you use:
- SSG — everything built to static HTML at build time. The default, and what most marketing sites and blogs use.
- DSG (Deferred Static Generation) — pages marked
defer: trueincreatePageare built on first request and then cached. Needs a serverless function at the host. - SSR — pages with
getServerDatarender on every request. Also needs a function at the host.
Check quickly:
grep -rn "defer: true" gatsby-node.* src/ | head
grep -rln "getServerData" src/ | head
If both come back empty, your site is pure SSG and every host below works, including the cheapest ones. If either hits, you need a host with adapter support or you need to remove the feature during the move.
Gatsby 5 deploys to hosts through adapters. Without an adapter Gatsby still produces a static public/ directory; with one, DSG/SSR routes, redirects from createRedirect, and headers are translated into the host's native format.
Netlify
The closest thing to a drop-in replacement, which is not surprising given who owns Gatsby now. gatsby-adapter-netlify is first-party and is auto-installed when Netlify detects a Gatsby 5 site; to pin it explicitly:
npm install gatsby-adapter-netlify
// gatsby-config.js
const adapter = require('gatsby-adapter-netlify').default;
module.exports = {
adapter: adapter({ excludeDatastoreFromEngineFunction: false }),
plugins: [/* remove gatsby-plugin-gatsby-cloud and gatsby-plugin-netlify */],
};
Supports SSG, DSG, SSR, createRedirect, and custom headers. Build minutes and bandwidth are metered on the free and Pro tiers; a large Gatsby site with long builds can use up free-tier build minutes quickly, so check build time before assuming the free plan will do.
Netlify also supports deploy previews per pull request, which replaces most of what teams used Gatsby Cloud previews for, minus the CMS-triggered content preview.
Vercel
Vercel has first-party Gatsby support and auto-detects the framework. SSG, DSG, and SSR routes all work; redirects from createRedirect are translated. A sensible choice if you expect to migrate to Next.js later, because the hosting, preview, and domain setup carry over unchanged.
Pricing is per seat on the Pro tier plus usage; a single-maintainer marketing site is usually fine on Hobby for non-commercial use, but commercial sites need Pro.
Cloudflare Pages and Workers
Cloudflare's Gatsby guide covers static deployment: connect the repo, set the build command to npx gatsby build and the output directory to public. Cloudflare is now steering new projects towards Workers with static assets, which serves the same public/ directory from the same edge network.
This is the strongest option for pure-SSG sites: generous free bandwidth, fast global delivery, and _redirects / _headers files in public/ for redirects and headers. There is no Gatsby adapter, so DSG and SSR routes are not supported; convert them to SSG or pick another host.
AWS Amplify Hosting
Amplify auto-detects Gatsby and builds from a connected repo; the Gatsby guide is still accurate. Good fit for teams already running on AWS who want hosting inside the same account and IAM boundary. SSG works out of the box; DSG/SSR are not supported through a Gatsby adapter, so treat Amplify as a static host for Gatsby. Redirects are configured in the Amplify console or amplify.yml, not from createRedirect.
S3 + CloudFront
The do-it-yourself option, and the cheapest at scale for a pure-SSG site. Build in CI, sync public/ to an S3 bucket, invalidate CloudFront:
npx gatsby build
aws s3 sync public/ s3://my-site-bucket --delete --cache-control "public,max-age=0,must-revalidate" --exclude "static/*" --exclude "*.js" --exclude "*.css"
aws s3 sync public/ s3://my-site-bucket --cache-control "public,max-age=31536000,immutable" --exclude "*" --include "static/*" --include "*.js" --include "*.css"
aws cloudfront create-invalidation --distribution-id E123EXAMPLE --paths "/*"
The two sync calls implement Gatsby's recommended caching headers: HTML must never be cached by the browser; hashed assets under static/ and the JS/CSS bundles are immutable. Redirects need a CloudFront Function or a CloudFront Key-Value Store lookup; trailing-slash handling needs a small function too, because S3 does not serve /about/ from about/index.html through CloudFront without one. No DSG/SSR.
GitHub Pages
Free, static only, and fine for small sites. Use gatsby-plugin-gh-pages-style workflows or, better, a GitHub Actions workflow that runs gatsby build and deploys public/ with actions/deploy-pages. No server-side features, no custom headers, and redirects are limited to meta-refresh pages generated by a plugin. Set pathPrefix in gatsby-config if the site lives under a repository path rather than a custom domain.
Feature support at a glance
| Host | SSG | DSG | SSR | createRedirect | Custom headers | Deploy previews |
|---|---|---|---|---|---|---|
| Netlify (adapter) | Yes | Yes | Yes | Yes | Yes | Yes |
| Vercel | Yes | Yes | Yes | Yes | Yes | Yes |
| Cloudflare Pages/Workers | Yes | No | No | _redirects file | _headers file | Yes |
| AWS Amplify | Yes | No | No | Console / amplify.yml | Yes | Yes |
| S3 + CloudFront | Yes | No | No | CloudFront Function | CloudFront | Build your own |
| GitHub Pages | Yes | No | No | Meta refresh only | No | No |
Cost, roughly
Exact prices change; check each host's pricing page before deciding. The shape is stable:
- Free tiers (Cloudflare, GitHub Pages, Netlify/Vercel free) cover a low-traffic SSG site indefinitely. The limiting factor on Netlify and Vercel is build minutes and commercial-use terms, not bandwidth.
- Paid platform tiers (Netlify Pro, Vercel Pro) are priced per seat per month plus usage, and are what a business site with DSG/SSR or team previews typically lands on.
- S3 + CloudFront is usage-only: cents per gigabyte plus request charges, usually the cheapest for high-traffic static sites, but you pay in engineering time for the CI, invalidation, and redirect plumbing.
- Amplify is usage-based like S3 + CloudFront with the plumbing done for you, at a higher per-gigabyte rate.
Our recommendation
- Pure SSG, small team, no AWS dependency: Cloudflare or Netlify.
- DSG or SSR in use: Netlify with the adapter, or Vercel.
- Already on AWS with IAM requirements: Amplify or S3 + CloudFront.
- Planning a Next.js migration within a year: Vercel, so the move is a repo change and nothing else.
Whichever you choose, remove gatsby-plugin-gatsby-cloud, delete the Gatsby Cloud preview webhook from your CMS, and pin your Node version in the host's build settings before the first deploy. If you would rather hand the move to someone who has done it a dozen times, our Gatsby maintenance and rescue service includes hosting migration.