TinaCMS is easy to understand when the example is a small documentation site or a marketing website with a few dozen pages. The harder question is what happens when the content archive becomes genuinely large.
Smashing Magazine gives us a much better test case.
The long-running publication moved away from WordPress in 2019, adopted a static Jamstack architecture, and later added TinaCMS to improve the writing and editing experience. TinaCMS now showcases Smashing Magazine as a site using the CMS to edit “10’s of thousands” of posts and pages. More importantly, Smashing Magazine still states on its website in 2026 that it is running on TinaCMS alongside Netlify and Swell.
That makes Smashing more useful than a vendor demo. We can examine a mature publication with a large archive, real editors, media assets, previews, deployments, and years of accumulated content.
But the conclusion should not be simply that “TinaCMS scales.” Smashing Magazine tells us something more specific: TinaCMS can work well for a large content repository when the publishing architecture, team culture, media strategy, and editorial workflow are compatible with a Git-backed CMS.
Why Smashing Magazine Is an Important TinaCMS Case Study
CMS case studies often make scale difficult to evaluate. A vendor might describe a customer as an “enterprise” without telling us whether the CMS manages 200 landing pages, 20,000 articles, or millions of structured records.
Smashing Magazine is different because we know something about both the history of the site and the workflow behind it.
Until 2019, Smashing Magazine used WordPress. It then migrated its large archive of articles, guides, and tutorials to a Jamstack setup. In its own account of the migration, Smashing reported roughly a sixfold improvement in page-speed performance.
The architectural change solved one class of problem but created another.
Content that had previously been authored inside WordPress was now stored in Markdown files. That was attractive from a development and infrastructure perspective, but writing and editing became less convenient. Contributors could write in Markdown or use tools such as Google Docs and Dropbox Paper, after which editors still needed to prepare the final content for the repository and publishing pipeline.
TinaCMS was introduced to close that gap. Smashing could keep its file-based architecture while giving editors something closer to a conventional CMS experience.
That context matters. TinaCMS was not selected in isolation. It was added to an architecture that already valued Git, static content, developer control, and deployment automation.
First, Define What “Large” Means
The Smashing example also exposes a problem with the question “Can TinaCMS handle a large site?”
Large is not one thing.
- Content scale: How many articles, pages, metadata files, and other records exist?
- Editorial scale: How many writers and editors work at the same time?
- Workflow scale: How many approval stages, publishing states, permissions, and review requirements are involved?
- Media scale: How many images, videos, PDFs, screenshots, and other assets need to be managed?
- Repository scale: How large and complex does the Git repository become?
- Delivery scale: How quickly can the site build, deploy, invalidate caches, and make an update live?
- Governance scale: How much access control, auditability, localization, compliance, and organizational separation is required?
Smashing Magazine gives us particularly strong evidence about content scale. TinaCMS itself says the implementation covers tens of thousands of posts and pages.
It does not, however, automatically demonstrate that the same architecture would suit a global newsroom with hundreds of editors, multiple regional publishing teams, complicated localization requirements, or half a dozen approval stages.
That distinction is essential when evaluating TinaCMS.
Lesson 1: Git-Backed Content Can Support a Serious Publishing Archive
TinaCMS is an open-source, Git-backed headless CMS. Instead of making a proprietary CMS database the primary home of the content, Tina can work with files such as Markdown, MDX, JSON, and YAML stored in Git.
Tina adds the CMS layer around those files: content models, editing interfaces, visual editing, an indexed data layer, and a GraphQL API.
For Smashing Magazine, that model had an important appeal. Its content could remain as tangible files in a repository the team controlled rather than becoming records that were meaningful only inside a particular CMS database.
At tens of thousands of posts and pages, the Smashing implementation is useful evidence against the idea that Git-backed CMSs are inherently limited to tiny websites.
There are also practical benefits to this architecture for a long-lived publication.
- Content is stored in common file formats.
- Git provides version history and rollback capabilities.
- Developers can manipulate content using familiar tooling.
- Content and code can participate in related review and deployment processes.
- The underlying articles are less dependent on a proprietary database format.
However, “Git can store 20,000 files” is not the same as saying that every publishing organization should put its content in Git.
The better evaluation question is: Does our content operation benefit from Git being the source of truth?
For a developer publication, documentation platform, technical knowledge base, or engineering-led content organization, the answer may be yes. For a newsroom built around deeply nontechnical editorial processes, it requires more scrutiny.
Lesson 2: Smashing Magazine Is an Unusually Good Cultural Fit for TinaCMS
This may be the most important qualification in the entire case study.
When Smashing Magazine described its TinaCMS implementation in 2023, it noted that while not everyone on the team was a developer, most or all of the team was comfortable working with Git and the command line.
That is not a minor implementation detail. It is part of why the architecture works.
TinaCMS can hide much of Git from an editor. An author does not necessarily need to open a terminal, manually create a branch, commit a file, or construct a pull request. Tina provides an interface around those operations.
But the underlying publishing model is still Git-shaped.
A draft may live on a branch. A protected production branch can prevent direct changes. A pull request represents a proposed publishing change. A merge can trigger deployment.
For Smashing, those concepts already fit the way the organization thinks about its website.
A less technical editorial team should therefore test the workflow rather than assuming Tina’s visual interface completely removes the organizational implications of Git.
The key distinction is between hiding Git mechanics and eliminating Git concepts. Tina is increasingly good at the former. Its architecture does not necessarily attempt the latter.
Lesson 3: Git Branches Can Become an Editorial Workflow
Git is normally discussed as developer infrastructure. Smashing shows how it can also become publishing infrastructure.
TinaCMS’s current Editorial Workflow allows teams to protect a branch such as main. When an editor tries to save a content change, Tina can create a new branch, index it, save the content there, and create a draft pull request.
The article can then be reviewed before the branch is merged into production.
For a publishing team, that creates several useful properties.
- Draft isolation: unfinished work does not need to modify the production branch.
- Previewability: branch deployments can produce a realistic preview before publication.
- Review: content can move through a pull request before being merged.
- Auditability: Git preserves a history of changes.
- CI checks: automated tests can run against content changes as well as code changes.
Smashing Magazine connected this model with branch previews. Editors could work on an article without putting it in front of the site’s live audience, then review the deployed version before merging it.
This becomes more interesting on a large site because content errors can have technical consequences. A malformed field, missing reference, broken component, or invalid file can be caught by a build or validation step before publication.
In that sense, Git-backed editorial workflow is not merely developer preference. It can become a form of publishing governance.
Lesson 4: Do Not Put a Large Media Library in Git Just Because Your CMS Is Git-Backed
One of the most practical details in Smashing Magazine’s implementation is what it didn’t put in the repository.
TinaCMS can work with repository-based media. For a smaller website, storing images alongside content can be convenient.
Smashing decided that approach would not make sense at its scale. The publication explicitly noted that putting its media assets into the Git repository would make the repository unmanageable.
Instead, its workflow used DigitalOcean Spaces for uploaded source assets. When the site rebuilt, images were processed and sent through Cloudinary for optimized delivery in different formats and sizes.
That gives large TinaCMS sites an architectural lesson worth copying even if they use different vendors:
- Git: articles, structured fields, metadata, schemas, and configuration.
- Object storage: source images and other heavy media.
- Media/CDN layer: resizing, transformation, optimization, caching, and delivery.
This distinction matters because “Git-backed CMS” should not be interpreted as “every content-related file belongs in one Git repository.”
At scale, media architecture deserves its own design.
Lesson 5: CMS Scale and Publishing Scale Are Different Problems
A CMS may handle tens of thousands of documents while the site’s deployment pipeline becomes the real bottleneck.
This is especially important for static and hybrid sites.
When an editor changes one article, what happens next?
Does the entire site rebuild? Does the framework rebuild only affected pages? Is the content fetched at runtime? How quickly is a preview generated? How long after a pull request is merged does the corrected article become visible to readers?
Those are not TinaCMS questions alone. They involve the framework, hosting platform, caching architecture, content API strategy, CI system, and deployment model.
A large-site TinaCMS evaluation therefore needs at least two performance measurements:
- Editor-to-preview time: how long it takes an editor to see a realistic version of a draft.
- Merge-to-live time: how long it takes an approved change to reach production.
A responsive editing interface does not compensate for a 20-minute publishing pipeline when a correction needs to go live immediately.
Likewise, an extremely fast deployment system does not help if navigating or searching the content repository becomes painful for editors.
Both layers need to be tested with production-sized data.
TinaCMS Has Also Changed Since Smashing Magazine’s 2023 Write-Up
There is another reason not to treat the original Smashing article as a permanent snapshot of TinaCMS.
The product has continued to evolve.
In December 2025, for example, TinaCMS published an update specifically addressing reliability problems in its Editorial Workflow. In the previous flow, users could navigate away while Tina was creating and indexing a branch and opening a pull request, unintentionally interrupting the process. Tina changed the interface to make the process more guided and resilient.
That update is useful for two reasons.
First, it shows that branch-based editorial workflows have real UX edge cases. Git operations that feel routine to developers still need careful abstraction when they become CMS actions.
Second, it shows that TinaCMS is still actively refining this part of the product rather than treating editorial workflow as finished infrastructure.
There have been more recent architectural developments too. In June 2026, TinaCloud added support for separate content repositories, allowing application code and Tina configuration to remain in one repository while Markdown or MDX content lives in another. Editorial branches and pull requests can operate on that content repository.
For a large publisher, that can be significant. Separating application development from a large and frequently changing content repository may make repository ownership, permissions, CI behavior, and maintenance easier to reason about.
Tina has also announced plans for TinaCMS v4. Among its stated goals is bringing branch and pull-request workflows further into the editor so content teams can work with Git without needing to spend as much time in GitHub.
That direction reinforces the central tradeoff highlighted by Smashing Magazine: Git is powerful publishing infrastructure, but the CMS still has to make it comfortable for editors.
What the Smashing Magazine Case Does Not Prove
The Smashing implementation is compelling, but it is easy to overgeneralize from a recognizable customer.
It does not prove TinaCMS is ideal for hundreds of nontechnical editors
Smashing Magazine’s familiarity with Git is unusually relevant. An organization where editors expect a completely conventional CMS workflow may experience the same architecture very differently.
It does not prove Git branches can model every editorial process
A branch and pull request can model draft-and-review workflows elegantly. A publisher may still require multiple approval stages, scheduled publishing, legal review, localization coordination, embargoes, granular roles, campaign dependencies, or regional governance that deserves separate evaluation.
It does not eliminate infrastructure work
Smashing’s architecture has involved TinaCMS, GitHub, Netlify, external object storage, Cloudinary, and its own publishing stack. That composability is part of the appeal, but it also means the CMS is one component in a broader system.
It does not mean every type of scale has been solved
Tens of thousands of content files are meaningful evidence of repository scale. They tell us less about an organization with hundreds of simultaneous editors, millions of media assets, dozens of locales, or unusually complicated permission structures.
A case study should tell us what is possible. It should not replace testing against our own workload.
Where AI Fits Into This Architecture
For publishers evaluating CMS platforms in 2026, AI also belongs in the discussion—but not in the usual “does the CMS have an AI writing button?” sense.
TinaCMS’s strongest argument remains its Git-backed content architecture and customizable editing experience. Its current documentation also discusses using external AI development tools such as GitHub Copilot and Cursor, but that is different from positioning Tina as an AI-first editorial platform.
For a large content operation, the more interesting question is how easily AI systems can work safely with the content model.
File-based structured content can be useful for workflows such as automated metadata generation, internal linking suggestions, content audits, bulk transformations, taxonomy cleanup, or migration assistance. Changes can potentially be expressed as Git diffs and reviewed before they are merged.
That can be attractive from a governance perspective. Instead of allowing an AI process to silently overwrite records in a production CMS, a team can design a workflow where machine-generated changes are reviewable before publication.
But TinaCMS does not automatically provide that governance architecture. Teams still need to decide which AI systems have access to content, what they may modify, how changes are validated, who reviews them, and which operations are allowed to reach production.
For large publishers, reviewability may ultimately matter more than the presence of a built-in AI button.
Who Is TinaCMS Most Convincing for at This Scale?
| Site or team | Fit suggested by the Smashing case | Why |
|---|---|---|
| Developer publication | Strong | Git, Markdown, previews, and technical workflows are natural fits. |
| Large documentation site | Strong | File-based structured content and version control can be valuable. |
| Technical knowledge base | Strong | Content can live close to developer tooling and review processes. |
| Content-heavy SaaS website | Potentially strong | Good fit when engineering owns or closely supports the publishing platform. |
| Marketing team with engineering support | Worth testing | The visual editor helps, but workflow and deployment need validation with real marketers. |
| Traditional newsroom | Needs closer evaluation | Complex scheduling, roles, approvals, and newsroom workflows may not map neatly to Git. |
| Hundreds of nontechnical contributors | Needs careful testing | Editor usability and governance become more important than repository capacity. |
| Media-heavy publisher | Viable with the right architecture | Heavy assets should be designed around external storage and optimized delivery rather than blindly committed to Git. |
How I Would Test TinaCMS Before Moving a Large Site
The best lesson from Smashing Magazine is not to copy its stack component by component. It is to test TinaCMS under conditions that resemble your real publishing operation.
I would include the following in a proof of concept.
- Import at least 10,000 representative documents. Do not evaluate navigation, indexing, search, and editor performance with a 20-page starter project.
- Use the real content model. Include relationships, authors, categories, metadata, embeds, code examples, reusable components, and unusual legacy content.
- Put nontechnical editors in the test. Developers are poor substitutes for the people who will spend hours in the CMS every day.
- Test branch creation and review repeatedly. Create drafts, revise them, abandon them, merge them, revert them, and deal with conflicting changes.
- Measure preview latency. Record how long an editor waits between saving a change and seeing a shareable preview.
- Measure publish latency. Record the time between approval or merge and the update becoming visible to readers.
- Test media at realistic scale. Include large images and a realistic asset library. Decide explicitly whether media belongs in Git or external storage.
- Simulate concurrent editors. Multiple writers working on separate branches is more informative than one developer editing one page.
- Break the workflow deliberately. Test failed builds, incorrect metadata, merge conflicts, deleted branches, interrupted operations, and rollback procedures.
- Test permissions and governance. Verify that the system reflects who is allowed to write, review, approve, merge, configure, and deploy.
- Benchmark migration. Convert a meaningful slice of the existing archive before committing to a platform-wide migration.
A CMS that performs well in this test is much more interesting than one that looks impressive in a polished demo.
TinaCMS vs. Other CMS Models for Large Publishers
The Smashing case also suggests a better way to compare TinaCMS with alternatives.
Do not start with a checklist asking which CMS has the largest number of features.
Start by asking where you want the canonical content and publishing workflow to live.
TinaCMS
Most compelling when Git ownership, file-based content, developer workflows, custom front ends, and an editor-friendly interface need to coexist.
Traditional CMS platforms such as WordPress or Drupal
Often more natural when the publishing organization wants the CMS itself to be the center of content operations and expects established editorial concepts without building as much infrastructure around the CMS.
Database-backed headless CMS platforms
Can be a stronger fit when structured content must serve many independent products, applications, locales, and channels while the organization prefers API-centric content infrastructure over Git-centric storage.
Other Git-based CMS options
Should be compared on editor experience, visual editing, content modeling, repository behavior, branch workflows, preview integration, media handling, deployment coupling, and the amount of custom engineering required.
The decision is architectural before it is cosmetic.
Verdict: What Smashing Magazine Really Tells Us About TinaCMS at Scale
Smashing Magazine gives TinaCMS something many CMS platforms lack: a credible public example of a mature content site using the system across a very large archive.
It demonstrates that Git-backed content does not have to stop being practical once a website grows beyond a few hundred Markdown files. It also shows how visual editing, branch previews, pull requests, external media storage, and automated deployment can combine into a workable publishing system.
But Smashing’s success should be interpreted in context.
This is a technically sophisticated publication. Its team was already comfortable with Git. Its publishing architecture was already built around Jamstack concepts. It deliberately kept heavy media outside the repository. And TinaCMS is only one layer in a broader infrastructure stack.
So the useful conclusion is not:
Smashing Magazine uses TinaCMS, therefore TinaCMS is suitable for every large publisher.
The better conclusion is:
TinaCMS can be a serious option for large content sites when the content model, engineering culture, editorial workflow, asset strategy, and deployment architecture all benefit from Git.
That is a narrower claim than saying TinaCMS “scales.” It is also a much more useful one for anyone deciding whether to build a large publishing operation around it.
