Static Site Generators in Production

Total Cost of Ownership for Static Site Generators

Framework comparisons usually weigh features and benchmarks. Budgets are decided by something else: how many hours the site costs every month for years after launch. A generator that builds in half the time but needs an engineer for every content change, or one that is free to host but breaks its theme on every major release, can cost several times more than the "slower" alternative. Hosting — the line item people ask about first — is almost never the deciding number.

This guide builds a three-year total-cost-of-ownership model for five realistic choices, using time logs from real sites where available and clearly labelled estimates elsewhere. It extends the SSG Framework Selection Matrix with the cost axis teams most often skip.

Prerequisites

  • A realistic picture of the site: page count, growth rate, how often it changes and who changes it.
  • Your team's loaded hourly cost (salary plus overhead); the model below uses 90 USD/hour as a placeholder.
  • Time logs or honest estimates from the last site you ran — they beat any published benchmark.

The Cost Components

Over three years, a static site's cost falls into six buckets:

  1. Initial build — scaffolding, templates, design, content migration.
  2. Content operations — hours per month spent on the mechanics of publishing, beyond writing itself: fixing build errors, asking an engineer for help, waiting on previews.
  3. Upgrades — generator, dependencies and runtime, including breakage from customisations.
  4. Feature work — search, forms, i18n, versioning: whatever the site needs beyond pages.
  5. Build and CI minutes — usually small, but real at scale.
  6. Hosting and services — CDN, functions, search, forms, monitoring.
Where three-year cost goes for a typical docs site A stacked bar of three-year cost for a 1,500-page documentation site. Content operations 38 percent, upgrades 21 percent, initial build 18 percent, feature work 17 percent, hosting and services 4 percent, and CI minutes 2 percent. Three-year cost by bucket, 1,500-page docs site content operations 38% upgrades 21% initial 18% features 17% hosting 4% · CI 2% People-time buckets: 94% · infrastructure buckets: 6% Time logs from one team's docs site over three years, valued at 90 USD/hour
Hosting is the smallest bucket; the ongoing cost of publishing and upgrading is the largest.

The Model

Five choices for a 1,500-page documentation-plus-blog site growing 30% a year, edited mostly by six writers with one part-time engineer. Hours are estimates grounded in time logs from comparable sites; adjust every number to your team.

Bucket (3 years, hours unless noted)HugoEleventyAstroStarlightNext.js export
Initial build (templates, migration)16015014070180
Content ops: engineer help per month × 366 → 2165 → 1805 → 1802 → 728 → 288
Content ops: writer friction per month × 3610 → 3608 → 28812 → 4325 → 18014 → 504
Upgrades406011090150
Feature work (search, forms, i18n)9090702090
People hours total8667689324321,212
CI minutes (USD)60120260180420
Hosting and services (USD)0–4000–4000–4000–4000–400
Approximate total (USD at 90/h)~78,000~69,000~84,000~39,000~109,000

The spread is almost entirely people time. Starlight wins here because it arrives with search, navigation and i18n configured (low feature work), its authoring is forgiving for writers (low friction) and it needs less initial template work. Next.js export is the most expensive because pure content does not benefit from its application features while writers and engineers pay for its complexity.

Three-year cost by generator Bars of estimated three-year cost for the model docs site: Starlight about 39,000 US dollars, Eleventy about 69,000, Hugo about 78,000, Astro about 84,000 and Next.js static export about 109,000. Infrastructure is under one percent of each bar. Estimated three-year cost (thousand USD) Starlight 39 Eleventy 69 Hugo 78 Astro 84 Next.js export 109 Model docs site, six writers, one part-time engineer; hours at 90 USD
A different team — engineers writing, no versioning, a design-heavy marketing site — would reorder these bars completely; the model matters more than this result.

Why Friction Dominates

The single largest line is writer friction: hours per month lost to build errors, waiting on previews, asking how to add a tab or an image, and fixing broken links. It is also the line teams never measure. Two numbers make it visible within a month: failed builds per 100 content changes (from CI), and the number of "how do I…" messages in the docs channel. On the site that informed the model, moving from MDX-everywhere to plain Markdown with a small component vocabulary cut failed builds per 100 edits from 4.1 to 0.9 — covered in MDX vs Markdoc for Docs Content — which alone was worth about five hours a month.

Build time enters here too, as a people cost. A 40-second preview versus a 4-minute preview is not a CI bill; it is six writers waiting, or context-switching, dozens of times a week. Astro vs Eleventy Build Times at 10,000 Pages quantifies how that scales.

Upgrade Cost Is Predictable

Upgrade cost looks unpredictable but follows two observable factors. Release cadence of breaking changes: count majors (and, for pre-1.0 projects, breaking minors) in the last 24 months. Depth of customisation: ejected or copied theme components, custom plugins against internal APIs, patched dependencies. Multiplying the first by the second, calibrated against your last upgrade's hours, predicted actual upgrade effort within about 30% across four sites. Keeping customisation shallow — the approach in Customizing Starlight Without Forking the Theme — is the most effective way to cut this bucket.

Upgrade hours by customisation depth Four points of annual upgrade hours against customisation depth for sites on the same generator. Configuration only: 6 hours a year. Component overrides: 14 hours. A few ejected components: 38 hours. A forked theme: 96 hours. Annual upgrade hours vs customisation depth 6 14 38 96 config only overrides some ejected forked theme Time logs from four sites on the same generator over two years
Customisation depth multiplied upgrade cost sixteenfold across otherwise similar sites.

The Exit Cost

A three-year model should include the cost of leaving, because most sites change generator eventually. Exit cost depends on how portable the content is: plain Markdown with standard front matter moves between generators in days, as the migrations in Migrating Between Static Site Generators show, while content full of framework-specific components, MDX imports and generator-specific shortcodes can take weeks. A simple proxy is the share of content files that contain anything other than Markdown and front matter; on the model site it was 9% for Hugo and Eleventy, 14% for Starlight and 38% for the Next.js MDX setup. Multiply by a per-file conversion estimate and add it to the table as a contingent cost. It rarely changes the ranking, but it often changes how teams write content from day one.

Hosting and Services, For Completeness

For the model site's traffic (about 1.2 million page views a month), static hosting on Cloudflare Pages, Netlify or GitHub Pages costs nothing, and paid tiers cost 20–50 USD a month where team features are needed. Self-hosting on S3 and CloudFront cost about 42 USD a month — see Deploying a Static Site to S3 and CloudFront. Hosted search is the one service that can become material: a commercial Algolia plan at this traffic would have been the largest infrastructure line; Pagefind costs nothing to run.

Using the Model

Treat the table as a template, not an answer. Fill it with your own team's numbers — hourly cost, who edits, how often, what features you need — and run it for the two or three generators that pass your hard requirements. The exercise is valuable even when the totals are close, because it forces agreement on who will maintain the site and how. Record the assumptions next to the decision; in a year, comparing actual hours with estimates is the best input to the next decision, and to the selection process in SSG Selection Checklist for Engineering Teams.

Pitfalls & Rollback

  • Optimising the hosting bill. It is usually under 5% of total cost. Optimise people time first.
  • Ignoring writer friction. It is the largest recurring cost and the least measured.
  • Assuming zero upgrade cost. Every generator has breaking changes; customisation depth multiplies them.
  • Copying someone else's model. A team of engineers writing their own docs has a completely different cost profile.
  • Rollback: a TCO model is an input to a decision, not a commitment; revisit it at each major upgrade with real numbers.

Conclusion

Over three years, the cost of a static site is overwhelmingly people: content operations, upgrades and feature work, with hosting and CI a rounding error. For a writer-maintained 1,500-page docs site, a docs framework with good defaults came out at roughly half the cost of general-purpose generators, and a Next.js export at nearly three times — but a different team would reorder that list. Measure friction, predict upgrade cost from cadence and customisation depth, and choose the generator that minimises the hours your team will actually spend.

FAQ

What dominates the cost of running a static site?

People. Engineering and writer time for setup, customisation, upgrades and support outweighs hosting and CI minutes by one to two orders of magnitude for almost every static site. Hosting is usually free or a few dollars a month.

Which generator is cheapest to own?

It depends on team skills more than on the tool. In our model, a Starlight docs site maintained by writers was cheapest for documentation, and Hugo was cheapest for a large, stable content site maintained by one engineer. Next.js static export was the most expensive for pure content.

How do I estimate upgrade cost?

Look at the generator's release history for the last two years, count breaking releases, and multiply by the hours your team spent on the last comparable upgrade. Customisations such as ejected theme components multiply that cost.

Should CI build minutes influence the choice?

Only at large scale or on paid plans. For most sites, build time matters for how long people wait on previews, which is a people cost, not a CI cost.