Conversation-first CMS for teams who manage structured content over Git.
Connect a repository, define content models, edit through chat or UI, review changes through Git-native workflows, and ship through forms, media, CDN, and APIs.
Contentrain Studio is an open-core, Git-backed content operations platform built with Nuxt 4. Teams can self-host the AGPL core or use a managed Pro/Enterprise offering while keeping Git as the source of truth.
The product model is:
- your Git repository remains the source of truth
- content is schema-based and locale-aware
- users can operate through chat, forms, or structured UI
- changes become branches, commits, diffs, and merges
- delivery can happen through media, CDN, and API surfaces
This repository contains the AGPL core. Proprietary enterprise implementations live in ee/ under a separate license. Managed Pro/Enterprise deployments can be operated on top of the same product model.
Traditional CMS products hide content workflows behind opaque databases and admin panels. Studio takes a different path:
- Git is the storage and audit layer
- schema validation protects structured content quality
- AI is bounded by tools and permissions, not used as an uncontrolled shell
- workspaces and projects map cleanly to team and repository boundaries
- self-hosting remains a supported trust path, and managed operation is also available
Studio shares the same .contentrain/ contract with the MIT package surface in the contentrain-ai repository. Developers usually enter the ecosystem through local-first package workflows, then move into Studio when review, roles, and delivery become operational needs.
| AI surface | Primary job | Studio bridge | Docs |
|---|---|---|---|
@contentrain/mcp |
Deterministic local content operations and normalize | Studio applies the same content contract through authenticated review and delivery workflows | MCP Tools |
contentrain CLI |
init, serve, generate, diff, validate |
Studio takes over when teams need a web surface, project management, and approval | CLI |
@contentrain/rules |
Shared quality and schema standards | Studio chat, review, and validation should stay aligned with the same rules | Rules & Skills |
@contentrain/skills |
Agent playbooks and workflow hints | Studio mirrors these workflows in onboarding, chat-led operations, and handoffs | Rules & Skills |
@contentrain/query |
Local typed consumption and CDN client transport | Studio extends the same content into remote delivery and API-key-based CDN access | Query SDK |
Typical path:
contentrain init → normalize hardcoded content → review in Studio → invite teammates → deliver through CDN/API when needed
- Workspace and project management
- GitHub App-based repository connection
- Structured content models:
- collection
- singleton
- document
- dictionary
- Multi-locale content workflows
- Chat-driven content operations
- Content validation and health reporting
- Branch, diff, merge, and review workflows
- Team and role management
- Media library and upload pipeline
- Forms and submission review
- CDN build and delivery surfaces
- Webhook and conversation API bridges
- Billing, plan limits, and self-host deployment fallbacks
- Core (
app/,server/,supabase/, tests): AGPL-3.0 - Enterprise (
ee/): proprietary implementations for premium operational surfaces
See:
User → Workspace → Project → Repository
- Workspace: billing, team, installation, and policy boundary
- Project: connected Git repository inside a workspace
- Content Engine: validation, serialization, branching, commit, merge
- Conversation Engine: AI loop with tool execution and permission enforcement
- Provider Layer: auth, database, git, AI, email, billing, CDN, media
| Layer | Current implementation |
|---|---|
| Framework | Nuxt 4 |
| UI | Radix Vue + Tailwind CSS 4 |
| Auth | Provider interface, currently Supabase Auth |
| Database | Provider interface, currently Supabase PostgreSQL + RLS |
| Git | Provider interface, currently GitHub App |
| AI | Provider interface, currently Anthropic |
| Provider interface, currently Resend | |
| Billing | Provider interface, currently Stripe |
| CDN / Media | Enterprise bridge-backed implementations |
The architectural rule is strict: application code talks to provider interfaces and shared utilities, not vendor SDKs directly.
Studio uses an open-core model and a plan/limit system.
Current runtime plans:
freestarterproenterprise
Examples of plan-differentiated capability:
- AI usage and BYOA
- CDN delivery and preview branches
- Media upload and custom variants
- Review workflow and advanced roles
- Conversation API and outbound webhooks
- Enterprise-only SSO, white-label, and custom domain surfaces
The source of truth for limits and feature checks lives in shared/utils/license.ts.
studio/
├─ app/ # Frontend pages, layouts, components, composables
├─ server/ # Nitro routes, middleware, providers, utilities
├─ supabase/ # Migrations, local Supabase config, RLS policies
├─ ee/ # Proprietary enterprise implementations
├─ tests/ # Unit, integration, Nuxt, RLS, and E2E suites
├─ .contentrain/ # Content models and generated query client
└─ docs/ # Release-facing deployment and self-hosting docs
- Node.js 22+
- pnpm 10+
- Git
- Supabase CLI for local database/auth flows
git clone https://github.com/Contentrain/studio.git
cd studio
pnpm install
cp .env.example .env
pnpm db:start
pnpm db:migrate
npx contentrain generate
pnpm devLocal app URL:
http://localhost:3000
Release-facing setup and deployment docs:
- Environment Reference
- Docker Guide
- Deployment Guide
- Releasing Guide
- Repository Hygiene
- Self-Hosting Guide
- Contributing Guide
- Security Policy
- Code of Conduct
pnpm lint
pnpm typecheck
pnpm test:unit
pnpm test:integration
pnpm test:nuxt
pnpm test:rls
pnpm test:e2e
pnpm test:ci
pnpm buildDo not open public issues for vulnerabilities.
Report security issues privately:
See SECURITY.md for scope, timelines, and disclosure guidance.
Studio is trunk-based. main is the single integration branch and the target for every PR. Staging is a Railway deployment environment fed from main, not a separate Git branch.
- Contributors: open PRs against
main(GitHub's default base, no extra step needed). - Self-hosters: deploy from tagged releases (
v0.1.0,v0.2.0, …). Tags are the stability contract;mainHEAD can include not-yet-released changes. - Releases: maintainers cut a version tag on
main→ production deploy. See docs/RELEASING.md.
Community contributions are welcome for the AGPL core.
Before opening a PR, read:
- Core: GNU Affero General Public License v3.0
- Enterprise directory: Proprietary license
If you run a modified version of the AGPL core as a network service, you must provide the corresponding source code to users of that service, consistent with AGPL obligations.
Built with Nuxt, Vue, Radix Vue, and Git-native content workflows.
Copyright 2026 Contentrain, LLC.