Keystone 6: A GraphQL-native CMS for Node.js teams that want the API and the admin UI from one schema

What Keystone actually is

Keystone 6 is a headless CMS and application framework for Node.js, published under the @keystone-6/* namespace. The README calls it a way to 'build faster and scale further than any other CMS or App Framework.' The core promise: you describe your schema, and Keystone gives you a GraphQL API and a management UI for your content and data. It is not a hosted service. It is a set of npm packages you run inside your own Node.js application. The project is maintained by Thinkmill Labs and licensed under MIT. This matters because it means you are not locked into a vendor's infrastructure, but you are also responsible for deploying and operating the Node process yourself.

How the schema becomes an API and a UI

The mechanism is schema-driven code generation. You define lists and fields in TypeScript, and Keystone compiles that definition into a GraphQL schema and a React-based admin interface. The README says 'describe your schema, and get a powerful GraphQL API & beautiful Management UI.' That is the entire data flow: schema in, API and UI out. There is no separate step to write resolvers or build CRUD endpoints. The generated API handles queries, mutations, and presumably filtering and pagination, though the README does not detail those specifics. The admin UI is not an afterthought; it is a core output, which distinguishes Keystone from libraries that only generate an API. If you need to customize behavior beyond what the schema allows, you can write custom resolvers or hooks, but the README does not explain how. The design trades flexibility for speed: you get a working backend quickly, but you inherit the conventions Keystone chooses.

Getting started with create-keystone-app

The README points to a getting started guide and a CLI tool called create-keystone-app. The intended first step is to run that CLI, which scaffolds a new project. The documentation lives at keystonejs.com/docs, with a dedicated getting started page. There is no command shown in the README itself, but the package name is enough to infer the typical usage: npx create-keystone-app or a global install followed by a create command. After scaffolding, you define your schema in a file, then run the development server. The README also mentions an examples directory in the repository, which contains runnable projects for learning specific features. For configuration, you will likely edit a keystone.ts file, though the README does not show it. The key point is that setup is minimal: one CLI command, then schema edits. There is no mention of a database setup step, but any real deployment will require one, and the docs presumably cover that.

Node version support is a hard boundary

Keystone 6 explicitly targets the Node.js Maintenance and Active LTS versions. The README states: 'Our @keystone-6/* packages are written for the Node Maintenance and Active LTS versions of Node; and our continuous integration seamlessly tracks that.' It warns that you 'may have success with Node versions that are Pending or End-of-Life, but you may have problems too.' This is a concrete constraint. If your organization runs an older Node version that is no longer in LTS, you cannot assume Keystone will work. You will need to upgrade Node first. This is not a minor detail; it affects deployment environments, CI pipelines, and any serverless platform that pins a specific runtime. The 'seamlessly tracks' phrase suggests the CI tests against those LTS versions, but it does not promise compatibility beyond them. For teams on current LTS, this is fine. For teams stuck on Node 14 or earlier, it is a blocker.

The trade-off: speed versus control

Keystone's value is speed of development. The README says 'no boilerplate or bootstrapping' and promises 'elegant APIs to help you ship the code that matters without sacrificing the flexibility or power of a bespoke back-end.' That last claim is ambitious. A generated CRUD API and admin UI are not the same as a fully bespoke backend. You can customize, but the schema is the source of truth, and any deviation from Keystone's model requires extra work. For example, if you need a non-GraphQL API, or a highly custom data access pattern, you will fight the framework. The README does not mention REST, authentication, or access control specifics, though those are likely covered in the docs. The honest assessment: Keystone is a strong fit for content-heavy applications where the schema maps cleanly to lists and fields. It is a weaker fit for applications with unusual data relationships or complex business logic that does not fit a CRUD pattern.

A real alternative: building your own GraphQL server

The most direct alternative is to build your own GraphQL server with a library like Apollo Server or graphql-yoga, combined with an ORM like Prisma or TypeORM. The difference in approach is fundamental. With Keystone, you declare a schema and get an API and UI for free. With a hand-rolled server, you write every resolver, every type, and every permission check yourself. That gives you total control over the API shape, but it costs significant time. The admin UI is the other differentiator. With a custom GraphQL server, you must build or integrate an admin panel separately, for example with a tool like AdminBro or a custom React app. Keystone bundles that UI, so you avoid the integration effort. The trade-off is that a custom server is more flexible for non-standard requirements, while Keystone is faster for standard content management. There is also the maintenance angle: a custom server has no external dependency on Keystone's release cycle, but you own all the code.

Maintenance, versioning, and community

Keystone follows semantic versioning, which is a positive signal for dependency management. The README states this explicitly. The project is not archived, and the last push was August 2026, with three releases in that month alone. That indicates active maintenance, though I cannot verify the content of those releases. The codebase is in TypeScript, which is a plus for type safety. The license is MIT, which means you can use it in commercial projects without paying a fee, but you should read the license text for exact terms; the README only says 'Licensed under the MIT License.' The project has a code of conduct and a security policy, which are good governance signals. One caveat: the README admits that the API reference is 'generally complete' but the guides and examples are 'still working hard on increasing the fidelity.' That means the documentation may be uneven. You should expect to rely on the API reference more than tutorials. The community is on Slack and Twitter, but the README does not mention a forum or issue tracker beyond GitHub.

Editorial conclusion

Adopt Keystone 6 if you are a Node.js team that wants a content model defined in TypeScript, a generated GraphQL API, and a built-in admin UI without assembling separate tools. Skip it if you need a fully managed CMS, a non-GraphQL API, or a system that supports Node versions outside Active LTS. Before committing, verify that your data relationships and access control needs fit Keystone's schema model, and check the current state of the guides and examples, which the README admits are still being improved. Keystone's own roadmap and semver releases are the place to confirm where the project is heading.

Official sources

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