Pruvious: a CMS that lives inside the Nuxt app

A Nuxt module that carries the admin interface in the same process

Pruvious is a content management system delivered as a Nuxt module, and the package description calls it "A reliable CMS for your Nuxt app." The pitch in the README is that you use Nuxt the way you normally would, and the CMS attaches itself to that app rather than sitting next to it as a separate service.

That decision shows up in the packaging. The package exports a Nuxt module entry point at ./dist/module.mjs and a separate config entry at ./config/index.ts, and it ships a bin entry named pruvious, which is the command line tool used to create a project. The repository is TypeScript, with src for the module source, a playground directory for local experimentation, test for the test suite, and a Dockerfile for a container build.

The audience is a team that already ships a Nuxt application and wants editors to change content without a redeploy of custom code. A marketing site, a documentation site, or a small product with a marketing front end fits that shape. It is a less natural fit for an organisation whose content is produced by a separate editorial team on a separate schedule, because the CMS then lives and dies with the app release cycle.

One init command installs Nuxt and wires the module together

The installation path is short enough to fit in one sentence, which is unusual for a CMS. The README says that to start a new project you use the pruvious init command, and that this command installs Nuxt and Pruvious and configures all the necessary settings.

# pnpm
pnpm dlx pruvious@3 init <dir>

# npm
npx pruvious@3 init <dir>

Replace <dir> with the path, relative or absolute, to an empty directory where the project should be initialised. The directory has to be empty, and the version is pinned to the 3 series in both invocations, so the scaffolder and the module you get afterwards are the same major line.

There is no separate step in which you add a dependency to package.json, and no manual configuration of the module in nuxt.config. The scaffold writes the project for you, which is convenient for a first run and also means the generated project is the only shape the team knows how to reproduce. A team that already has a Nuxt codebase and wants to add the CMS to it will find that the documented path starts from an empty directory rather than from an existing app.

Storage is chosen through NUXT_PRUVIOUS environment variables

Pruvious does not hardcode one database. The package.json scripts make the switching mechanism visible, and the variables are the NUXT_PRUVIOUS_ prefixed ones, which is the Nuxt convention for runtime configuration that can be set per environment.

The variables cover three concerns. A database connection is set through NUXT_PRUVIOUS_DATABASE, and the value is a full connection URI rather than a set of separate host and port fields. A cache or session store is set through NUXT_PRUVIOUS_REDIS, again as a URI. File uploads are handled by a drive, and the drive is configured with a group of variables: NUXT_PRUVIOUS_UPLOADS_DRIVE_TYPE selects the driver, NUXT_PRUVIOUS_UPLOADS_DRIVE_KEY and NUXT_PRUVIOUS_UPLOADS_DRIVE_SECRET are the credentials, NUXT_PRUVIOUS_UPLOADS_DRIVE_BUCKET and NUXT_PRUVIOUS_UPLOADS_DRIVE_REGION describe where the objects live, and NUXT_PRUVIOUS_UPLOADS_DRIVE_ENDPOINT plus NUXT_PRUVIOUS_UPLOADS_DRIVE_BASE_URL tell the module how to reach that endpoint and what public URL to hand back for a stored file.

The dev:s3 script in package.json shows all of that in one line, pointing the drive at a local Minio instance on port 9000 with a bucket named pruvious. The practical reading is that the module is storage agnostic, and that the deployment environment, not the code, decides where the content physically lives.

The same test suite runs against SQLite, PostgreSQL, Redis and S3

The testing section of the README is unusually explicit about the backends, and it doubles as documentation of what the module actually supports. The default test run uses SQLite and needs no external service.

pnpm test

The PostgreSQL variant needs a local database named pruvious_test on the default port 5432, with the username pruvious and the password 12345678. The setup instructions give the three statements to run inside psql, creating the database, creating the user with that password, and altering the database owner to that user.

pnpm test:pg

Redis is the third case, and the README names the database index and the port the tests expect.

pnpm test:redis

S3 is the fourth, and here the README is prescriptive about the local object store: it recommends Minio, and it gives the commands to install and start it on MacOS, then describes opening the Minio admin dashboard on the local port 9000, creating a public bucket named pruvious, setting the server location in the region settings to pruvious, and creating an access key named pruvious whose secret key is also pruvious.

pnpm test:s3

What this buys a reader is certainty about the supported matrix. A module that passes its suite against four storage configurations is a different proposition from one that assumes a single database, and the cost of that breadth is a test setup that needs local services for three of the four runs.

Collections, fields and blocks are defined in a playground you can edit

The README describes a playground folder as a Nuxt test environment for Pruvious, and the point of it is that you can create collections, fields, blocks and other configurations there to try them out before they shape the real application. The playground is loaded automatically when you run pnpm dev, which means the admin interface is available as soon as the dev server is up, with no separate seeding step described in the README.

The vocabulary here is the content model rather than the deployment. A collection is a type of content, a field is a property on it, and a block is a richer composable piece of content that a page can be assembled from. A CMS built on that vocabulary lets an editor lay out a page from blocks instead of filling a fixed form, and it is the reason a module of this kind is worth evaluating at all for a marketing or documentation site.

The documentation is split across two places, and the README points at both. The main documentation lives at pruvious.com/docs, and there is a separate tutorial at pruvious.com/tutorial that the README describes as a practical demonstration of building a website from scratch. The feature list itself is not in the README, so the depth of what the admin can do, which roles exist, whether drafts and scheduling are supported, and how the API is shaped, has to be read in the docs rather than judged from this repository.

The container build targets x64 and expects a PORT

The Dockerfile is short enough to read in full and contains two constraints worth knowing before deployment. The build stage installs openssl and git, then runs npm install with --production=false and --arch=x64. The comment above that line explains the reason: the build output is meant to run on an x64 server, and the argument was added to make sure the output runs as expected on non x64 processors. The comment also says that on an arm or non x64 host this argument has to be removed.

The production stage is thinner. It copies the built output across, sets NODE_ENV to production, and passes the PORT environment variable through with an ENV PORT=$PORT line, which means the host has to supply PORT and the image does not set a default of its own.

CMD [ "node", ".output/server/index.mjs" ]

That last line is the process the container runs, the Nuxt server output. So the whole CMS, the admin panel included, is served by the same Node process as the site, which is the point of the design and also its main scaling limitation.

A module and a hosted API service take different routes to the same content

The alternative to an in-process CMS module is a hosted or separately deployed content API that your Nuxt app calls over HTTP. The difference in approach is not the editor interface, which both approaches can have, but where the content and the admin code live and who has to run them.

With Pruvious, the admin, the schema and the content share one deployment unit. The CMS is versioned with the application, a rollback of the app is a rollback of the CMS, and there is no second service to monitor, scale or secure. The cost is that the CMS inherits the app's release rhythm, its runtime limits, and the same database and storage decisions. There is also no way to edit content without deploying a new version of the app code that hosts it.

With a separate content API, the editor can publish while the front end is frozen or being rolled back, the content service can be scaled on its own, and its uptime no longer depends on the app. The cost is an HTTP boundary, a second deployment, a second set of credentials, and a schema contract that has to be maintained on both sides. Choosing between them is a question of whether publishing content and releasing code are the same event in your organisation. When they are, the module approach is simpler. When they are not, the simplicity is the wrong kind.

Release cadence: v3.16.1 in June 2026 after a long gap at v3.15.6

The version history is worth reading closely. The release list shows v3.16.1 and v3.16.0 both published on 2026-06-06, and before them v3.15.6 on 2025-11-19. The last push was on 2026-06-06, which is also the date of the two most recent releases.

Two things follow. The minor line moved from 3.15 to 3.16 in that window, so the change of behaviour a team inherits when upgrading is not a patch level. And the gap between v3.15.6 and the 3.16 releases is over six months, which tells you the release cadence is not fixed to a schedule. A team that pins a version and wants predictable upgrades should not assume a patch arrives every few weeks.

The licence is MIT, which is the permissive choice and permits use in a commercial application, modification and redistribution, with the customary notice and licence text retained. No separate commercial licence is mentioned for the module itself, and the hosting and documentation live on the project site rather than in the repository.

Editorial conclusion

Pruvious fits a product team whose content is edited by people who already deploy the same Nuxt application, and it does not fit a content operation that needs independent scaling, independent releases, or an editor workflow outside the deploy cycle. Before adopting it, decide which database the module will use in production, since the same codebase runs on SQLite, PostgreSQL and Redis and the choice is made through environment variables, and read the storage driver keys in package.json to confirm the upload path matches where your files will live.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. pruvious/pruvious on GitHub
4. README
5. Releases