Nuxt Studio: editing a Nuxt Content site from the production site itself

What Nuxt Studio is and how it changed

Nuxt Studio is a visual edition in production for a Nuxt Content website. Originally offered as a standalone premium platform, Studio has evolved into a free, open-source and self-hostable Nuxt module, with the stated goal of enabling an entire team to edit website content right in production.

That reframing matters for anyone evaluating it. The product used to be a hosted service you paid for, and the current shape is a module you install in your own Nuxt application, which means the data, the auth and the deployment are yours. The homepage is nuxt.studio and the documentation lives at the same address, and there is a live demo at docus.dev/admin.

The feature list is long and it is worth reading as three groups. There are the editors: a Monaco code editor for enhanced Markdown with MDC syntax, YAML and JSON, a TipTap visual editor with MDC component support which is the default mode, and a form-based editor for YAML and JSON files and frontmatter with auto-generated forms based on collection schemas. There is a Vue component props editor for editing component props directly. And there is AI-powered content suggestions, described as a plug and play integration with the Vercel AI Gateway.

Then the plumbing: real-time preview of your changes on the production site, file management for the content directory including create, edit, delete and rename, a centralised media library supporting JPEG, PNG, GIF, WebP, AVIF, SVG and more, and Git integration that commits changes directly from the production website so your CI/CD pipeline deploys them.

Then the access model: multi-provider OAuth login with GitHub, GitLab and Google, utilities for implementing your own auth flow such as password, SSO or LDAP, a development mode that edits the local filesystem directly, and full i18n across 25 languages.

Installing the module and enabling development mode

The module is added with the standard Nuxt module command.

npx nuxi module add nuxt-studio

That is the whole of the local setup, and the README says so explicitly: run your Nuxt app and you will see a floating button on the bottom left for editing your content, and any file changes are synchronised in real time with the file system.

The note underneath is the constraint that catches people out. The publish system is only available in production mode. To publish locally you have to go back to the classical workflow, the IDE, the command line, GitHub Desktop and so on. In other words, in development the module is an editor over your working copy, and the browser-based commit flow only appears once the site is deployed.

The production configuration goes into nuxt.config.ts, and it has two parts: where Studio lives and where it commits to.

export default defineNuxtConfig({
  modules: [
    '@nuxt/content',
    'nuxt-studio'
  ],
  
  studio: {
    // Studio admin route (default: '/_studio')
    route: '/_studio',
    
    // Git repository configuration (owner and repo are required)
    repository: {
      provider: 'github', // 'github' or 'gitlab'
      owner: 'your-username', // your GitHub/GitLab username or organization
      repo: 'your-repo', // your repository name
      branch: 'main', // the branch to commit to (default: main)
    }
  }
})

The modules array shows the dependency clearly, since the Studio editor edits Nuxt Content collections and needs the content module present. The owner and repo fields are marked as required, and the branch defaults to main.

Production setup: Git provider, auth provider and SSR

Three things have to be configured before the browser editor works on a live site, and one of them is a deployment constraint rather than a setting.

The Git provider is where the content is stored, so a GitHub or GitLab repository, and the configuration above already covers it.

The auth provider is how users log in to reach Studio. The choices are GitHub, GitLab, Google OAuth, or your own authentication, and the GitHub case is set with environment variables.

# Example with GitHub OAuth
STUDIO_GITHUB_CLIENT_ID=<your_client_id>
STUDIO_GITHUB_CLIENT_SECRET=<your_client_secret>

The .env.example file in the repository shows the full set, grouped by provider. There are the GitHub client id and secret, the GitLab application id and secret, and the Google client id and secret, and in each case a moderators variable listing who may sign in. There are also token variables for using a GitHub or GitLab provider together with Google OAuth, and a group for SSO with a URL, a client id and a client secret pointing at the separate nuxt-studio-sso project.

The moderators list is the part to get right. It is the only thing standing between a public URL and a write access to your content repository, and an empty list is a configuration that grants nobody access rather than everybody, so a team enabling Studio for the first time should set it before anything else.

The deployment requirement is the hard one. Nuxt Studio requires server-side routes for authentication, and the site must be deployed on a platform that supports SSR using nuxt build. A site built as a static export has no server routes and therefore no way to run the OAuth callback, so the module cannot work there at all. Once deployed, you open the configured route, /_studio by default, and authenticate to start editing.

The configuration options in full

The configuration reference is short, and every option has a documented default, which makes it easy to see what a minimal configuration looks like.

export default defineNuxtConfig({
  studio: {
    // Studio admin login route
    route: '/_studio', // default

    // Git repository configuration
    repository: {
      provider: 'github', // 'github' or 'gitlab' (default: 'github')
      owner: 'your-username', // your GitHub/GitLab owner (required)
      repo: 'your-repo', // your repository name (required)
      branch: 'main', // branch to commit to (default: 'main')
      rootDir: '', // subdirectory for monorepos (default: '')
      private: true, // request access to private repos (default: true)
    },
  }
})

Two of these deserve attention. The rootDir option, empty by default, is the subdirectory for monorepos, which is the case where a documentation site lives alongside other packages in one repository and the content lives in a subfolder. And the private flag, true by default, controls whether Studio requests access to private repositories, which is the setting that determines whether a self-hosted Studio on a private repository works at all.

The provider default is github, and the alternative is gitlab, so the module supports both of the two large Git hosting services without a plugin, and a custom auth flow covers everything else.

Developing the module and running its checks

Contributing is a matter of cloning the repository and using the playground in dev mode, with the dev option set to true. The README adds a caveat for the production path: to contribute with production mode you have to create a local GitHub OAuth App pointing at http://localhost:3000 as the callback URL.

The development setup is a pnpm workspace with two processes, the playground and the app dev server, and a preparation step that generates the type stubs.

# Install dependencies
pnpm install

# Generate type stubs
pnpm dev:prepare

# Build the app and service worker
pnpm prepack

# Terminal 1: Start the playground
pnpm dev

# Terminal 2: Start the app dev server
pnpm dev:app

You then log in at http://localhost:3000/admin, which is the playground rather than the Studio route, because the playground is a test site with the module mounted.

The project structure explains the split between the module and the editor.

studio/
├── src/
│   ├── app/           # Studio editor Vue app
│   └── module/        # Nuxt module
├── playground/        # Development playground
│   ├── docus/         # Docus example
│   └── minimal/       # Minimal example

The checks can be run as one command or individually, and the one-shot version is the useful one for a contributor.

# Global verify running all needed commands
pnpm verify

The individual commands are the same set.

pnpm test
pnpm typecheck
pnpm lint

The package.json shows what verify actually does, since it chains the preparation step with the lint, the build, the type check and the tests in order. That ordering is the reason to use it rather than running the pieces yourself, because a type error in the generated stubs shows up in the type check and a lint error in the module source shows up earlier.

The package is published under the name nuxt-studio at version 1.8.0, under the MIT licence, with the module as the main export and separate exports for the app and its service worker.

Where Nuxt Studio is the wrong choice

The first limitation is the SSR requirement. The site has to be deployed on a platform that supports server-side routes, using nuxt build. A static export, which is the cheapest way to host a documentation site, cannot run Studio, and there is no static fallback. For a project on a static host, this rules the module out unless the hosting changes.

The second is that the write path is a Git commit, and every edit goes through it. The feature list says commit changes directly from your production website and just wait for your CI/CD pipeline to deploy your changes. That means the review model is whatever your pipeline has, and a team with a required pull request review gets a commit that then needs to be merged. The tool does not mention pull requests or approvals, so a governance-heavy team will have to build that around it.

The third is the trust boundary. Anyone who can sign in and is on the moderator list can commit to your content repository, and the content repository is the same one your build reads. The moderators list is the control, and the default for the private flag means the module will ask for access to a private repository on your behalf. That is convenient and it is also a meaningful grant.

The fourth is the editor coverage. There are three editors for three content shapes, and the form-based editor depends on collection schemas being defined, so a site with loose frontmatter gets less out of the form editor. The Vue component props editor only helps for sites that actually use components with editable props.

The fifth is the feature roadmap. The feature list names planned items, a collections view for managing content collections in a unified interface, media optimization inside the editor, and an AI content assistant, and the project also asks for community-driven feature suggestions through discussions. The tipTap editor being the default mode, with the code editor as the alternative, is a design decision that some teams will want to reverse, and switching modes is a user-level choice rather than a configuration one.

Licence, maintenance and the cost of an in-browser CMS

The project is under the MIT licence, with a license.md file at the root of the repository and the same declared in the package metadata. It is published on npm under the name nuxt-studio at version 1.8.0, with the module as the main entry point and separate exports for the editor app, its shared utilities and its service worker.

The repository is not archived and the last push was on 2026-10-16, the same day as the v1.8.0 release, so the module is actively maintained. The release history shows v1.7.0 in April 2026 and v1.6.1 a few days before that, so the cadence is a few releases a year with patch releases inside a line.

The cost of the module itself is one dependency in a Nuxt application, and the operational cost is one more thing to keep current, since a module that runs in production and holds write access to your repository is not something you leave unmaintained for a year.

The real cost is the process change. A team that previously published content by opening a pull request now has a path that bypasses the pull request, and the value of Studio is entirely in making that path safe for the people who are not developers. That means the moderators list, the branch configuration and the pipeline all become part of the security model of the site, whether or not anyone thinks of them that way.

The self-hostable turn is what makes that model workable. A hosted version of this would have to be a trusted third party with write access to your content, and a module is not. The trade is that you now operate the authentication, the OAuth applications and the SSR deployment yourself, which is a smaller commitment than trusting someone else with the keys, and a larger one than not having a browser editor at all.

Editorial conclusion

Nuxt Studio suits a team whose editors should not have to open a text editor and a Git client to fix a typo on a marketing page, since the module turns the deployed site into the editor and writes back through a commit. It does not suit a static site with no server, because Studio requires server-side routes and a build with nuxt build. Check your hosting platform supports SSR before you plan around it, and set the moderator list before you open the route to your whole team.

Frequently asked questions

Official sources

1. License: MIT
2. nuxt-content/nuxt-studio on GitHub
3. Project website
4. README
5. Releases