Learn Gatsby - Deployment & Hosting

#Introduction

Deployment is the stage where the static build output is served to users. Because Gatsby's output is pure HTML, CSS, and JavaScript files, the site can be hosted almost anywhere — from managed platforms to bare object storage.

Episode 20 covers the Gatsby Cloud, Netlify, and Vercel deployment options, build output and deploy previews, domain and CDN management, and cache invalidation with production workflows.

#Deployment and Hosting Options

#Managed Platforms

Gatsby Cloud, Netlify, and Vercel offer managed builds: repositories are watched, builds run in the cloud, and the results are distributed directly through a CDN. All three support per-pull-request deploy previews and per-environment environment variables. There's no server to maintain — the whole deploy cycle happens on the platform's infrastructure.

#Pure Static Hosting

The public output can also be uploaded to an object storage bucket like S3 or Google Cloud Storage paired with a CDN. This option is the cheapest and most controlled, but the build has to run somewhere else, such as your own CI. Choose this path when you already have your own cloud infrastructure and want full control over costs. The tradeoff: you're responsible for builds, caching, and asset updates.

#Comparing the Three

Considerations when picking a platform: ease of repo integration, preview support, build speed (especially for large sites that need incremental builds), and how costs are calculated. Gatsby Cloud sits closest to the Gatsby ecosystem, while Netlify and Vercel offer additional services like forms and edge functions. List your site's needs, then match them against each platform's features before deciding.

Also watch out for switching costs: exclusive platform features — like incremental builds on Gatsby Cloud — tie a project to one vendor. Consider whether that feature can be replaced with your own CI work so the project stays portable.

#Build Output and Deploy Previews

#Understanding the public Folder

gatsby build produces a public folder containing all the static assets ready to deploy:

npm run build
npx serve public

serve public serves the output locally for testing. It's this public folder that gets uploaded to hosting — not the project source. All pages, hashed assets, and pointer files like 404.html are already complete inside this folder.

#Deploy Previews

Almost every platform provides a preview URL for each pull request. Previews enable visual review before a change is merged, while also verifying that the build still succeeds on the feature branch. Preview URLs usually appear automatically on the pull request page once the build finishes. Use previews to check content, interactions, and basic performance before approving a merge.

#Deploy via Git Integration

Connect the repository to the platform, then every push to a branch triggers an automatic build. This is a common Netlify configuration:

[build]
  command = "npm run build"
  publish = "public"
 
[build.environment]
  NODE_VERSION = "20"

The command section runs the Gatsby build, and publish points to the public folder. Environment variables like NODE_VERSION are set here so the Node version stays consistent.

#Domain Management and CDN

#Custom Domains and DNS

After deploying, point a custom domain at the platform by adding a CNAME record. Some platforms offer automatic verification; also make sure to enable HTTPS with automatic certificates. Apex domains usually use an A record or the platform's redirect service to the www version.

#The Role of the CDN

A CDN stores copies of assets in many geographic locations, reducing latency. Managed platforms already include a CDN in front, while static hosting needs an extra CDN like CloudFront or Cloudflare for maximum performance. The effect is noticeable for visitors across countries: content is served from the nearest edge server rather than the origin region. Measure the improvement by comparing load times from several locations before and after the CDN is active.

#Cache Invalidation and Production Workflows

#Hashed Assets and Cache Headers

Gatsby names bundle assets with a content hash, so asset caching can last a long time without the risk of serving old versions. HTML pages are sent with non-cached headers so updates appear immediately.

#Cache-Control for HTML and Assets

Define cache headers explicitly on the platform. An example on Netlify via netlify.toml:

[[headers]]
  for = "/*"
  [headers.values]
    Cache-Control = "public, max-age=0, must-revalidate"
 
[[headers]]
  for = "/static/*"
  [headers.values]
    Cache-Control = "public, max-age=31536000, immutable"

Cache-Control: max-age=31536000, immutable lets the CDN store hashed assets for a year because the filename changes every time the content changes. Meanwhile, HTML uses must-revalidate so the newest version is always fetched.

#Production Workflow

Every production change goes through the same steps: push to a branch, build in CI, test, deploy preview, then promote to production. Automating these steps makes releases routine instead of stressful. Keep release notes and make sure every team member knows who is allowed to promote to production. Also define a rollback strategy — a fast way to revert to a previous version if a problem surfaces after release.

#Conclusion

Key takeaways:

• The public output is the result of a Gatsby deploy.
• Gatsby Cloud, Netlify, and Vercel provide managed builds and CDN.
• Deploy previews verify every pull request.
• A custom domain is connected via CNAME and HTTPS.
• Hashed assets enable long-term caching.
• Cache headers for HTML and assets are configured separately.

In the next episode, episode 21, we'll discuss headless CMS and content platforms — integrating multiple content sources, headless setup best practices, preview workflows, and managing content as code.