Webiny v6: The AI-Programmable Self-Hosted CMS

We've been building Webiny for developers working on hard problems. Multi-tenant platforms. Content infrastructure for large organizations. SaaS products that need to embed content management without building it from scratch. Complex editorial operations spanning multiple teams, brands, and markets.

v6 is the largest release we've shipped. Not because we added the most features — because we made a set of interconnected decisions that change what it means to build on top of Webiny. This post walks through what changed, why it changed, and what it means for teams already running v5.

Here's the short version if you're not reading the whole thing:

AI-programmable via a local MCP server — AI agents now have deep, expert-level knowledge of Webiny's architecture and best practices, running entirely in your environment. No data leaves your infrastructure.
Single-package project structure — the monorepo is gone. One entry point, one pattern, dramatically simpler codebases that new developers can orient in without a senior guide.
Website Builder replaces Page Builder — your framework renders the pages, your infrastructure hosts them. CSR, SSR, and ISR all supported. Custom components registered with a single prompt. Comes with a Next.js starter kit.
Headless CMS: field-level permissions and layout components — control view/edit access per field, and structure content models with sections, tabs, and conditional visibility rules.
Webiny SDK — stop writing GraphQL queries by hand. The SDK handles it with proper TypeScript types and significantly less boilerplate.
Tenant Manager with programmatic API — create, install, configure, and disable tenants via API. The feature that makes Webiny viable as a SaaS backend.
Overhauled Publishing Workflows — simpler for editors and reviewers, fewer support requests landing in developer inboxes.
New UI built on shadcn and Tailwind — predictable, customizable, and no longer looks like legacy enterprise software.
Learn Webiny course — a structured path from zero to productive, replacing the "dig through reference docs and hope" experience.

The Positioning Shift: What "AI-Programmable" Actually Means

Migrating from v5

v6 is a significant release. The project structure change alone means this is not a trivial upgrade.

We're currently building and actively testing a migration utility for v5 → v6. It's not ready yet, which is why we're not shipping it yet. When it's complete and tested, it will be documented and announced properly. If you're planning a migration now and have a specific use case, reach out directly — we want to understand the real-world scenarios the utility needs to cover.

What v6 Is, Honestly

Every change in v6 attacks the same underlying problem: the cost of complexity compounds over time when the platform works against you.

The monorepo was costing teams maintenance overhead. The Page Builder was costing teams flexibility. The missing SDK was costing teams boilerplate. The flat content model forms were costing editors accuracy. The tenant management UI was costing SaaS teams automation they needed. The reference-manual-only documentation was costing new developers ramp-up time.

v6 addresses those costs systematically. The AI-programmable positioning isn't a marketing layer on top — it's a natural consequence of building a platform with explicit conventions, strong typing, consistent patterns, and open architecture. Those properties are what make a platform legible to agents. We built them because they're good engineering. They also happen to be exactly what makes AI-assisted development work.

Go install it. Tell us what we got wrong.