Gatsby builds a fast, React-based static blog with a mature plugin ecosystem, and it is no longer the default choice it was five years ago, which makes the question of whether to start a new blog on it worth answering honestly before you spend a weekend on it.
The short version: if you already know Gatsby, it will build you a very good blog. If you are choosing fresh in 2026, there are lighter tools that do the same job with a fraction of the concepts. Here is the actual setup, the part that confuses everyone, and the honest comparison.
Table of contents
- What Gatsby is doing under the hood
- Getting a blog running
- Creating a page per post
- The parts that will cost you an afternoon
- Should you pick it for a new blog
- Deploying it
- How this fits the rest of the stack
- FAQ
What Gatsby is doing under the hood
Gatsby is a React framework that runs your components at build time and writes out HTML. Visitors get static pages that then hydrate into a React application, so navigation between pages happens client-side without a full reload.
The distinctive part is the data layer. Gatsby pulls content from anywhere, markdown files, a CMS, an API, a spreadsheet, into an internal GraphQL schema at build time. Your components then query that schema for exactly the fields they need.
This is the thing people either love or bounce off, and it is worth understanding why it exists. The pitch is one uniform query language across every content source, so switching from local markdown to a hosted CMS means changing the source plugin rather than rewriting components.
The counter-argument is equally fair. For a blog whose content is fifty markdown files in a folder, a GraphQL layer between you and the folder is a substantial amount of machinery to learn in order to read some files. Whether that trade is worth it is genuinely a matter of what else you are building.
Getting a blog running
The starter is the fastest honest path:
npm init gatsby my-blog -- -y
cd my-blog
npm run developOr start from the blog starter, which arrives with markdown sourcing, a post template and pagination already wired:
npx gatsby new my-blog https://github.com/gatsbyjs/gatsby-starter-blog
cd my-blog && npm run developThe development server runs on port 8000, and GraphiQL, the interactive query explorer, runs at /___graphql on the same port. Open it. It is the single most useful tool for learning the data layer, because it shows you the schema that actually exists rather than the one you assumed.
The pieces that make a markdown blog work are three plugins and a bit of config:
module.exports = {
plugins: [
{
resolve: 'gatsby-source-filesystem',
options: { name: 'posts', path: `${__dirname}/content/posts` },
},
'gatsby-transformer-remark',
'gatsby-plugin-image',
'gatsby-plugin-sharp',
],
};The source plugin makes files visible to the data layer, the transformer turns markdown into HTML and frontmatter into queryable fields, and the image plugins handle responsive images at build time.
Creating a page per post
Gatsby does not automatically make a page per markdown file. You write that in gatsby-node.js, which is the step that surprises people coming from simpler generators.
exports.createPages = async ({ graphql, actions }) => {
const { createPage } = actions;
const result = await graphql(`
{
allMarkdownRemark {
nodes { id, frontmatter { slug } }
}
}
`);
result.data.allMarkdownRemark.nodes.forEach((node) => {
createPage({
path: `/blog/${node.frontmatter.slug}`,
component: require.resolve('./src/templates/post.js'),
context: { id: node.id },
});
});
};The template then queries for the single post using the id passed in context:
export const query = graphql`
query($id: String!) {
markdownRemark(id: { eq: $id }) {
html
frontmatter { title, date(formatString: "MMMM D, YYYY") }
}
}
`;Alternatively, file-system routing lets you skip gatsby-node entirely for simple cases by naming a file with a bracket parameter. It is less flexible and considerably less code, and for a straightforward blog it is the better starting point.
The parts that will cost you an afternoon
- Build times grow with post count, and the GraphQL layer plus image processing is where the time goes. A few hundred posts with images is a multi-minute build. Gatsby Cloud used to mitigate this and no longer exists in the form it did, so the incremental build story is weaker than it was.
- Image processing is heavy. gatsby-plugin-sharp generates multiple sizes and formats per image at build time, which is why the output is excellent and the build is slow. Keep source images reasonable or the build will punish you.
- GraphQL errors at build are the usual first wall. A query for a field that does not exist fails the whole build with a message that points at the schema rather than your typo. GraphiQL is how you check before guessing.
- Plugin ecosystem age. Many Gatsby plugins were last updated years ago. Check the publish date before depending on one, especially anything touching a third-party service.
- The framework itself is in maintenance rather than active development. It works, and it is not where new feature work is happening.
None of these are dealbreakers for a personal blog. All of them are worth knowing before committing a team to it.
Should you pick it for a new blog
An honest answer, by situation.
- You already know Gatsby and have a working mental model of the data layer. Yes, use it. The productivity of knowing a tool beats the marginal benefits of a newer one.
- You want a React blog and expect to add dynamic features later. Reasonable, though a full-stack React framework with static generation is the more actively developed path.
- You want a fast content site and do not specifically want React. Pick a lighter static generator. You will ship sooner and ship less JavaScript.
- You are building a large site with many content sources and a team. The uniform data layer genuinely helps here, and it is the case Gatsby was designed for.
- You want to write posts and not think about tooling. Managed WordPress or a hosted blog platform, without apology. The best blogging setup is the one that does not compete with the writing.
The trap worth naming: picking a framework because it is fast, when what makes a blog fast is that it is mostly text served from a CDN. Almost every static generator achieves that. The differences between them are about authoring experience and build time, not about the number a speed test gives you.
Deploying it
A Gatsby build produces a public directory of static files, which is the easiest thing in the world to host:
npm run build # writes ./public
npm run serve # preview the production build locallyPoint a host at the repository with build command gatsby build and publish directory public, and every push rebuilds and deploys. Set the Node version explicitly, because a mismatch between your machine and the build environment is the most common cause of a build that works locally and fails remotely.
Two configuration details worth getting right. Cache the fingerprinted asset files aggressively and the HTML briefly, because Gatsby fingerprints its JavaScript and CSS so those can be cached indefinitely. And add a redirect rule for any URL structure you are migrating from, since changing a blog’s URLs without redirects discards whatever search ranking the old ones had.
On RunxBuild a Gatsby blog is a static site deployed from GitHub: build command, publish directory, custom domain and certificate handled, with headers and redirects configurable per path and 120GB of bandwidth included before it bills at ten cents a gigabyte. A text-heavy blog will not come close to that ceiling.
How this fits the rest of the stack
A blog is the cheapest thing you can host, which is worth remembering when the tooling decision starts feeling weighty: it is a pile of HTML on a CDN, and the running cost barely moves whichever generator produced it. The RunxBuild hosting calculator makes that concrete by showing bandwidth and build separately from the service and database lines you would only need if the blog grew into something else, which is a useful reality check before spending a weekend comparing frameworks.
Useful related references:
- Gatsby CMS Options: Choosing the Content Layer
- Astro Islands Architecture: Ship HTML, Hydrate Only What Moves
- The Best CMS for Hugo: Git-Based, Headless, or Neither
- Builds on RunxBuild
FAQ
Is Gatsby still worth using in 2026?
For a blog, yes if you already know it, and probably not if you are choosing fresh. It still produces excellent static sites, but it is in maintenance rather than active development, the plugin ecosystem has aged, and lighter generators do the same job with far fewer concepts to learn.
Why does Gatsby use GraphQL for local markdown files?
So that every content source, whether files, a CMS or an API, is queried the same way. That uniformity pays off on a large site with several sources and is mostly overhead on a blog with fifty markdown files, which is the most common complaint about the framework.
How do I create a page for each blog post in Gatsby?
Either write a createPages function in gatsby-node.js that queries all posts and calls createPage for each one with a template and a context id, or use file-system routing by naming a template file with a bracket parameter. The second is much less code and enough for a simple blog.
Why is my Gatsby build so slow?
Usually image processing. The sharp plugin generates multiple sizes and formats for every image at build time, which is why the output is good and the build is not. Oversized source images are the most common cause, followed by a large post count combined with the GraphQL layer.
Where should I deploy a Gatsby blog?
Anywhere that serves static files from a CDN, since the build output is a plain directory of HTML and assets. Point a host at the repository with gatsby build as the command and public as the publish directory, pin the Node version, and set cache headers so fingerprinted assets are cached long and HTML is not.