KeystoneJS 6: A Schema-First GraphQL CMS and App Framework for Node.js

The problem KeystoneJS 6 solves for Node.js teams

Most Node.js backends end up writing the same layer twice: once as the domain model, and once as the CRUD endpoints and admin screens on top of it. KeystoneJS 6 attacks that duplication by making one schema file the source of truth. The README states that you "describe your schema, and get a powerful GraphQL API & beautiful Management UI for your content and data." The audience is a development team that wants a bespoke backend but does not want to hand-write resolvers and list views for every entity.

The project is published to npm under the @keystone-6/* namespace, so this is a library you install into your own application rather than a service you sign up for. That distinction matters: the data lives in your database, the server runs on your infrastructure, and the schema is code under version control. The pitch in the README is "No boilerplate or bootstrapping" alongside "without sacrificing the flexibility or power of a bespoke back-end." Those two goals pull against each other, and the rest of this article is about where the tension shows.

How a Keystone schema becomes an API and an admin UI

The repository layout tells you a lot about the architecture. The top level holds packages/, prisma-utils/, docs/, examples/, tests/ and tests2/. The presence of prisma-utils/ and a dedicated test:filters script that runs pnpm verify inside that directory indicates that Prisma sits underneath Keystone's data layer and that filter generation is handled by a separate utility rather than by the main packages. Prisma is not mentioned in the README, so treat that as an inference from the directory structure rather than a documented guarantee.

The build and release machinery is also visible. The root package.json sets packageManager to [email protected], runs preconstruct build for the build script, and uses Changesets (ci:version-packages runs node scripts/prepare-release.js && changeset version) for versioning. A postinstall hook runs preconstruct dev followed by a recursive check across workspaces. If you clone the monorepo rather than installing the published packages, that postinstall step is what wires the workspace together.

On the client side, the README describes the stack as built with GraphQL and React, and the examples directory includes custom-admin-ui-logo, custom-admin-ui-navigation and custom-admin-ui-pages. Those names indicate the admin UI is extensible at defined points rather than being a closed surface. The examples also include custom-field, custom-session, custom-session-jwt, custom-session-redis, custom-session-next-auth, custom-session-passport and custom-output-paths, which suggests sessions and output paths are configuration concerns rather than fixed behaviour.

Getting started with KeystoneJS 6

The README points to the Getting Started page on keystonejs.com, which it says walks you through first steps with the create-keystone-app CLI. That CLI is the documented entry point. The README does not list its flags or the prompts it presents, and it gives no literal install command, so the only thing that can be stated with confidence is the package name and the script the root package.json exposes for building the monorepo.

npx create-keystone-app

If you are working inside a clone of the repository instead of a generated app, the root package.json defines the build and install steps the maintainers use.

pnpm install
pnpm build

After the generator finishes, the README's suggested reading order is the Why Keystone page for what ships in the box, then the API Reference for the foundational building blocks, then the Guides for walkthroughs. The repository also carries an examples directory that the README calls "a growing collection of projects you can run locally to learn more about a Keystone feature." If your use case is file uploads, examples/assets-local and examples/assets-s3 are the closest starting points; for authentication, examples/auth and examples/auth-magic-link.

Node version is the one hard constraint stated in the README: the @keystone-6/* packages "are written for the Node Maintenance and Active LTS versions of Node." The README adds that you may have success on Pending or End-of-Life versions, "but you may have problems too." Check your runtime against the Node.js release schedule before filing a bug.

The README is explicit that the documentation is uneven. It says the API Reference is "generally complete" while the team is "still working hard on increasing the fidelity of our guides and examples." That is an unusually candid note, and it should shape how you plan: budget time for reading source in examples/ when a guide stops short.

Where KeystoneJS 6 is the wrong choice

The clearest limitation is documented, not inferred. If you are running Keystone 5, the README states that the codebase "is now in maintenance mode and lives at keystonejs/keystone-5." There is no migration path described in the README itself; it points to a Keystone 5 and beyond issue for more information. A team on 5.x is therefore looking at a rewrite of the schema and admin customisations, not a version bump.

The second limitation is the documentation gap the README admits to. When the API Reference is complete but guides and examples lag, the cost lands on whoever has to implement a feature that no example covers. The README invites you to open a GitHub discussion to request an example, which is a reasonable process but not a schedule.

The third is the framework's shape. KeystoneJS 6 generates a GraphQL API and an admin UI from a schema. If your product needs a hand-tuned REST surface, or an editorial experience that does not resemble a generated admin panel, you are working against the grain of the tool rather than with it. Nothing in the README suggests a REST-first mode.

Finally, the README does not document rollback, downgrade procedures, or what happens to generated database migrations if you revert a schema change. That silence is worth noting before you treat the schema file as freely reversible.

KeystoneJS 6 compared with a general-purpose framework like NestJS

The honest comparison here is not with another headless CMS but with a general Node.js framework, because that is the decision most teams actually face. A framework such as NestJS gives you modules, dependency injection and controllers, and you write the data layer, the API surface and any admin tooling yourself. KeystoneJS 6 inverts that: you declare the entities and their fields, and the GraphQL API and management UI are produced from that declaration.

The difference shows up in what you own. With NestJS, every endpoint is explicit and there is no generation step between your intent and the HTTP surface. With KeystoneJS 6, the generated API is the surface, and your customisation goes through the extension points the examples demonstrate, such as custom-admin-ui-pages or custom-field. That is faster for content-shaped applications and slower for anything that does not fit the schema-to-CRUD pattern.

A second axis is the data layer. The prisma-utils/ directory and the test:filters script indicate Prisma is doing the database work, which means your schema choices are constrained by what that layer supports. A framework where you write the queries directly has no such constraint, at the cost of writing them.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-08-20. Releases were published on 2026-08-11, 2026-08-18 and 2026-08-20, so the project is being published on a short cadence. That cadence is the maintenance signal you have; the README does not publish a support window or an LTS policy for Keystone itself.

Upgrade cost is governed by semver, which the README states the project follows. The changeset tooling in the root package.json (ci:version-packages, @changesets/cli, @changesets/changelog-github) means releases are accompanied by generated changelogs, so the intended workflow is to read the changelog for the version you are moving to. The README does not describe a deprecation policy or how long old majors receive fixes.

The licence is MIT, held by Thinkmill Labs Pty Ltd, with the copyright line reading 2024. MIT is permissive: it allows commercial use, modification and redistribution provided the copyright notice and permission notice are retained. This is a description of the licence text, not legal advice; if your organisation has rules about attribution in distributed software, have counsel read the LICENSE file rather than this paragraph. One practical consequence is that you can fork the project if upstream direction changes, which is a real option under MIT and not under a copyleft licence.

Editorial conclusion

Adopt KeystoneJS 6 if your team already writes TypeScript and wants a GraphQL API plus an admin UI generated from one schema file, and if you accept that the guides and examples are, in the README's own words, still being improved. Do not adopt it if you want a hosted CMS with no code, or if you are on Keystone 5: that codebase is in maintenance mode at keystonejs/keystone-5. Before committing, check that your Node version is a Maintenance or Active LTS release, and open the examples directory for the feature closest to your use case.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes