Open-Source CMS Built on shadcn/ui: What Source-Available Means

"Open source" is one of those words that has lost its edge through overuse. WordPress is open source. Strapi is open source. Sanity Studio is open source. So is UnfoldCMS — but the four ship under different licenses, with different rules about what you can do with the code, and "open source" alone doesn't tell you what matters for a shadcn-based CMS.

This post explains the source-available story for an open-source CMS built on shadcn/ui, what "you own the code" actually means at the licensing level, and how that differs from the closed-vendor model most CMS buyers default to.

Disclosure: I work on UnfoldCMS. UnfoldCMS is source-available, not open-source-by-OSI-definition. I'll explain the distinction without softening it.

TL;DR — the open-source picture for shadcn CMSs

shadcn/ui itself is MIT-licensed — copy any component, change anything, ship commercially, no obligation. A CMS built on shadcn can choose its own license: MIT (Payload, Strapi for community edition), AGPL (Directus core), or source-available (UnfoldCMS). All four ship the code; the differences matter when you fork, redistribute, or run as SaaS. For a private CMS for your own sites, all four work. For a multi-tenant service or a forked redistribution, the license picks itself.

What "you own the code" means at the licensing level

The phrase comes from shadcn/ui itself. The components live in your repo, not behind an import { Button } from 'somewhere'. You can read every line, change every line, ship the modified version commercially. That's the MIT license doing its job.

When a CMS is built on shadcn/ui, that ownership extends to the admin code:

• The 51 shadcn components in cms/resources/js/components/ui/ are MIT (from upstream shadcn) and yours to modify.
• The 205 admin pages in cms/resources/js/pages/admin/ are the CMS's own code, licensed under the CMS's chosen license.

Whether the admin pages are MIT, AGPL, source-available, or proprietary depends on the CMS. shadcn doesn't dictate that.

The four licensing buckets you'll see

1. MIT / Apache 2.0 — fully permissive

Examples: Payload CMS, Strapi (community edition), Directus core.

You can fork, modify, redistribute, run as SaaS, charge customers — anything, with attribution. No copyleft. The CMS company makes money via hosted tier, enterprise support, or premium plugins.

Trade-off: the CMS company funds development from a smaller revenue base because anyone can host it for free. Some have raised VC to bridge this; some have struggled. WordPress.com (Automattic) and Strapi Cloud are the dominant examples of "MIT + SaaS" working at scale.

2. AGPL — strong copyleft

Examples: Directus has used AGPL for its core in some configurations.

You can fork and modify, but if you run a modified version as a service, you must release your modifications. This stops SaaS providers from forking-and-running without contributing back, which is why AGPL exists. For internal use or self-hosted client work, AGPL is mostly invisible.

Trade-off: AGPL has reputational baggage in enterprise procurement — some legal teams reject it on sight. For most indie devs and small agencies, AGPL is fine. For Fortune-500 contracts, you check first.

3. Source-available (commercial)

Examples: UnfoldCMS, Sentry's main repo, MongoDB's SSPL.

The full source code ships. You can read it, modify it, run it on your own infrastructure for your own sites and your own clients' sites. You cannot redistribute the modified version as a competing CMS, cannot resell licenses, cannot run it as a multi-tenant SaaS for unrelated customers. The license is paid (one-time or subscription).

This is where UnfoldCMS sits. It's not OSI-approved open source, and we don't claim to be. We claim "you can read every line, fork the admin for your sites, modify anything, host yourself." For most CMS buyers (devs running their own sites, agencies running client sites, indie SaaS founders), that's the same set of rights they care about.

4. Proprietary / closed source

Examples: Contentful, Webflow, most hosted enterprise CMSs.

You don't get the code. You get an API and an admin URL. Lock-in is the business model.

This is what shadcn-built CMSs are explicitly not. The whole point of shadcn — "you own the code" — collapses into nothing if the CMS around it is closed.

What shadcn-built means for an OSS CMS, specifically

The interesting case is option 3 (source-available) and option 1 (MIT) when paired with shadcn/ui as the admin layer.

Source-available + shadcn admin: you get the admin code, you can modify any of the 51 components, you can fork the 205 admin pages, you can theme everything via Tailwind v4 CSS variables. You can't redistribute the modified CMS as a competitor. For agencies shipping ten client sites, this works — each site is your site, modified for the client, hosted on the client's infrastructure.

MIT + shadcn front-end (Payload, Strapi): the admin is not shadcn — it's the vendor's React lib. shadcn lives only on your separate Next.js / Astro front-end app, which can be MIT or any license you choose for your project. You get full MIT freedom on the front-end and on the CMS itself, but the admin design system isn't shadcn.

Both work. The picker question is: do you want the admin to be shadcn, or just the front-end?

For the longer comparison, see I Tested 7 CMS Options for shadcn/ui — Here's What Works and shadcn CMS vs Payload: Honest Admin UX Comparison.

What "fork the admin" actually means in practice

A common worry from open-source-aware buyers: if I customize the admin, what happens when the CMS updates?

For a shadcn-built admin, the answer mirrors how shadcn handles upstream changes in any project:

• You pull updates as code, not as npm update. The update is a git diff against your fork.
• If you've modified components/ui/data-table.tsx, you'll see a merge conflict on update if upstream also changed that file. Resolve like any merge.
• If you've added entirely new pages in pages/admin/, upstream changes don't touch them.

The 18 local modifications we have on the 51 shadcn components today (UnfoldCMS source tree) survived every Tailwind v4 migration, every React 18→19 upgrade, every component prop addition. None were lost. None were "auto-overwritten." Git is the persistence layer for your customisations.

When source-available is the right pick

• You're an agency shipping client sites and need to modify the admin per-client without rebuilding it.
• You want the security of "I can read every line of this CMS" without the obligation to redistribute changes.
• You don't intend to redistribute the modified CMS as a product, just to use it yourself.
• The one-time license fee is cheaper than the developer-time cost of forking an MIT CMS to match your needs.

When MIT-licensed is the right pick

• You plan to redistribute the modified CMS publicly.
• You're running a multi-tenant SaaS where the CMS itself is part of the service you sell to customers.
• Your legal team has a hard rule against any non-OSI license.
• You don't need shadcn in the admin — Payload, Strapi, Directus all work.

When AGPL is the right pick

• You're building the CMS itself and want to ensure forks contribute back.
• You're a contributor to the CMS upstream and want strong copyleft.
• Your enterprise legal team is okay with AGPL (not all are).

People Also Ask

Is UnfoldCMS open source?

UnfoldCMS is source-available, not OSI-approved open source. The full source ships with every license. You can read every line, modify any component, fork the admin for your own sites, and self-host. You cannot redistribute a modified version as a competing CMS or resell licenses. For most CMS buyers, this gives the same set of rights they care about as MIT.

Can I modify the shadcn admin in UnfoldCMS?

Yes — every shadcn component lives in cms/resources/js/components/ui/ and every admin page in cms/resources/js/pages/admin/. Fork them the same way you'd fork any shadcn component: copy, edit, commit. Updates pull as code, not as npm packages.

What's the difference between source-available and open source?

Open source (OSI definition) requires that you can redistribute and modify freely, including as part of a competing product or commercial service. Source-available ships the code but typically restricts redistribution as a competitor or as multi-tenant SaaS. For self-hosting your own sites, the two are practically identical.

Can I use UnfoldCMS for client sites?

Yes — that's the agency use case. Each client site is yours (or the client's) to host, modify, theme. The license covers self-hosting your work and your clients' work. What it doesn't cover is reselling UnfoldCMS itself as a competing product.

Is shadcn/ui open source?

Yes — shadcn/ui ships under MIT. Every component is in your repo when you npx shadcn add, and you can modify, redistribute, and commercialise the result. The CMS built on shadcn picks its own license; shadcn doesn't dictate that.

Bottom line

For a CMS buyer in 2026, the licensing decision usually comes down to: do you need MIT-style freedom to redistribute, or do you just need the right to read and modify the code for your own use? If the latter, source-available CMSs like UnfoldCMS work and the one-time pricing is often cheaper than the alternative DevOps time. If you need MIT, Payload / Strapi / Directus are good options — they just don't ship a shadcn admin.

If "I want to read every line, modify the admin, self-host, but not redistribute as a product" describes you, try the UnfoldCMS demo or see the pricing tiers.

Sources and methodology

• shadcn/ui license — MIT, confirmed at the shadcn/ui repo.
• Payload license — MIT, confirmed at the Payload repo.
• Strapi community license — MIT, confirmed at the Strapi repo.
• Directus license — historically AGPL on core; check the current Directus repo for the latest before relying on this.
• UnfoldCMS counts — find cms/resources/js/components/ui -name "*.tsx" \| wc -l = 51; find cms/resources/js/pages/admin -name "*.tsx" \| wc -l = 205.
• All licenses cross-referenced June 2026.