The team operating surface for governed content in Git
Studio is the team operating surface for Git-native content: chat-driven content work, structured editing, review branches, roles, media, CDN, forms, webhooks, and usage controls.
Operating model
A team surface over Git, not a separate content database
Studio operates structured content through a content engine that validates, serializes, branches, commits, and reviews files. The repository remains the audit layer while the app gives non-developers a usable workspace.
- Workspace and project management
- Model-aware content editing for collections, documents, dictionaries, and singletons
- Branch detail views for review and moderation
AI workflow
Conversation-first content operations
Studio chat is not a generic prompt box. The server builds project context, filters available tools by permissions, and streams bounded operations that create, update, review, or inspect content through the same governed path.
- Tool-driven content operations
- Project and permission context in the conversation layer
- Conversation history and external conversation API surfaces
Governance
Roles, review, and branch health for teams
Studio adds the controls that local tools do not need: workspace members, project roles, model-scoped access, reviewer flows, branch health checks, and moderated merge or reject paths.
- Owner, admin, member, editor, reviewer, and viewer surfaces
- Model-level access constraints in project permissions
- Branch health and diff review before content reaches production
Delivery
Media, CDN, forms, and webhooks are part of the system
The Studio codebase includes asset management, media processing, CDN routes, form configuration, submissions, and webhook dispatch. That turns content governance into delivery infrastructure instead of a writing screen only.
- Asset manager and media variants
- CDN manifest and route surfaces
- Forms, submissions, and webhook settings
AI keys
BYOA and managed usage paths support different teams
Studio supports workspace AI keys and managed agent usage paths, with billing, usage, and overage surfaces in the app. Teams can decide whether to bring provider keys or use a managed Studio experience.
- Workspace AI key management
- Usage and overage panels
- Billing checkout and portal integration points
Commercial path
The open-core path is clear
Developers can start with the MIT packages, then use Studio when collaboration, delivery, and governance are worth paying for. Self-hosted and enterprise paths can use the same product shape without forcing content out of Git.
- Open-source developer adoption channel
- Studio SaaS for collaboration and delivery
- Self-managed options for infrastructure-sensitive teams
Common questions
Is Studio required for Contentrain projects?
No. Studio is the team and delivery layer. Developers can start with the CLI, MCP, rules, skills, and SDK packages locally.
What does Studio sell that the MIT packages do not?
Studio sells collaboration, review, permissions, media, CDN, forms, billing, usage controls, and managed team workflows around the same Git-native content contract.
Does Studio bypass Git?
No. Studio is designed around Git-backed content operations, branches, commits, diffs, validation, and controlled merge paths.
Next paths
Continue through the content system
Studio adoption playbook
Move from local packages into seats, review, media, CDN, and enterprise paths.
Content editor workflow playbook
Give editors Studio workflows without losing Git review.
Content teams solution
How non-developers operate content with review.
Pricing
How SaaS and license revenue map to the Studio surface.
Start local. Scale to Studio.
Build a governed content layer before content becomes product debt.
Developers can start with the MIT packages. Teams can move into Studio when review, roles, delivery, and licensing matter.