I’ve been following TinaCMS for a while now, and the v4 announcement deserves some serious thought. Not hype. Real thought.

The core shift is this: v4 is leaning hard into a plugin-first, highly extensible architecture. It’s moving away from the idea that the CMS should be a monolith that tries to solve everyone’s problem, toward something more like a toolkit where you build exactly what you need.

(See the official v4 announcement{:target=“_blank”} on the TinaCMS blog for the full details.)

This is interesting. Let me break down what I’m excited about, and what I’m still uncertain on.

What Excites Me

1. The Dynamic Plugin System

TinaCMS’s dynamic plugin system isn’t new, but v4 is doubling down on it. The key innovation: plugins can be added and removed at runtime, not just at startup. This changes everything about how you structure a CMS interface.

Why this matters: Most CMS plugins are static. You declare your plugins in config, they load, and they stay loaded forever. TinaCMS lets you say: “Show content creation options only when we’re in the blog section. Disable them elsewhere.” Context-aware UI.

This is elegant. It moves the responsibility of “which features should be available where” from the CMS author to the developer integrating it. That’s how you do inversion of control.

Beyond plugins, the team is also reworking the forms system around React Hook Form, rebuilding field types for consistency, and bringing Git workflows further into the editor itself (so content teams don’t need to live in GitHub). These are solid areas for improvement.

2. Content Stays in Git

This is the non-negotiable for me. TinaCMS is Git-native by design. Your content lives in your Git repository, not in some proprietary database. You get version control, history, rollbacks, CI/CD integration—all the things engineers expect from their tools.

Other headless CMSs have tried to position themselves as developer-friendly, but they still lock your content away in managed infrastructure. With TinaCMS v4, the philosophy is clearer: content as code. Treat your markdown files like source code.

3. Extensibility Without Abandonment Risk

Here’s a fear I have with any CMS: What if they stop developing it? What if the company pivots? With proprietary systems, you’re trapped. With TinaCMS, even if the company disappeared tomorrow, your content is in Git. You can still version it, edit it, migrate it.

The v4 plugin architecture takes this further. If TinaCMS v4 becomes stale, you can fork it or migrate to something else while keeping 100% of your content. That’s genuine peace of mind.

What I’m Watching

1. The Complexity Tax

Extensibility is powerful, but it’s also complex. Every plugin system has this same tension: the more customizable the base system, the more cognitive load on developers using it.

The real question is: “How much do I have to understand about TinaCMS internals to build something simple?” If the answer is “too much,” then v4 skews toward developer-only territory instead of staying developer-friendly.

2. The Learning Curve for Custom Integrations

Building a custom plugin requires React knowledge, hooks, understanding the TinaCMS API surface, plugin lifecycle, etc. This is fine for engineers building complex content workflows. But what about smaller teams or projects that just need a “slightly different form”?

Early TinaCMS had a simpler learning curve for basic customizations. If v4 requires deeper knowledge for smaller wins, that’s a tradeoff worth being honest about.

3. Ecosystem Maturity

The real power of a plugin system only emerges when there’s a rich ecosystem of plugins. TinaCMS v4 is betting that developers will build plugins, share them, and that over time this becomes a self-reinforcing network.

But on day one of v4, that ecosystem is sparse. The early question: Do third-party developers embrace the plugin architecture, or do they build competing solutions?

This isn’t a TinaCMS problem specifically—it’s a broader question about plugin systems. Some markets solve this beautifully (VS Code, Figma plugins, WordPress). Others fizzle. TinaCMS’s success here depends on developer adoption and a clear incentive structure for plugin authors.

4. The V3-to-V4 Migration Path

The elephant in the room: Are there v3 projects out there? How painful is the migration?

The announcement addresses this well. V3 will stay supported, and v4 is shipping as a brand new package (@tinacms/tinacms), so projects can adopt it when ready. The team is planning a codemod to handle schema migrations and promises clear docs on breaking changes.

If it’s a clean upgrade path with good documentation, great. If existing users get stuck or forced into a rewrite, that’s a credibility hit. The announcement suggests they’re thinking about this, but we won’t know until people actually try it.

What This Means for the Broader CMS Ecosystem

TinaCMS v4 is betting that Git-native, developer-centric workflows are the future. And I think they might be right. Content stored in Git, edited through a beautiful UI, versioned with code—that appeals to developers who are tired of proprietary databases and vendor lock-in.

But here’s the thing: This appeals specifically to developers, not to content teams that just want an intuitive interface. The more TinaCMS leans into the “for developers” positioning, the more it cedes ground to systems like Contentful or Sanity on the “for teams” side.

That’s not a bad thing. Specialization is healthy. But it’s worth naming explicitly.

The Honest Take

I’m genuinely interested in TinaCMS v4. The plugin architecture is solid. The commitment to Git is refreshing. The extensibility focus appeals to me as an engineer.

But I also know v4 is still half-baked. The ecosystem isn’t there yet. The upgrade path isn’t totally clear. Building advanced customizations looks complex.

What I’m waiting for: Real v4 projects in production, built with custom plugins, shipped by teams of varying sizes. That’s when we’ll know if this vision actually works at scale.

Until then, I’m cautiously optimistic. If the plugin ecosystem actually grows and the migration story is smooth, TinaCMS v4 could be genuinely interesting for developers who care about content-as-code.

And if it’s not? Well, at least the content will still be in Git.

Have thoughts on TinaCMS v4? I’m thinking about this actively and would be interested in hearing what excites or concerns you—especially if you’re already using v4 in production.