Roadmap

We know the highest priority for our users is guides and walkthroughs of how to implement various solutions with Keystone, so we're planning to greatly expand this part of our documentation (including corresponding example repos)

Keystone has so far focused on delivering a great GraphQL API for front-end apps to use. We're expanding on this with first class support for accessing the same APIs from Node.js so you have more flexibility in how you write your apps, including hybrid use-cases.

These new APIs will make fetching and updating your Keystone data from custom GraphQL queries and resolvers, express apps, and server-side frameworks like Next.js incredibly straight-forward.

Keystone's GraphQL API has been stable (no breaking changes!) for several years now. While this has been great for building front-end apps with confidence, it has held us back from fixing some pain points (like error handling) for a while now.

We take the stability of code written against Keystone very seriously, and with that in mind are planning to make some changes to the API that we expect to provide backwards-compatibility and streamlined migration stories for.

Deploying a database-backed application to production is still surprisingly complex, and it can be challenging to find the right tradeoffs and hosting providers. So we're looking at ways Keystone can help streamline these options.

This will include building for serverless environments, targeting different architectures for your GraphQL API and Admin UI applications, and independent dev, build and startcommands. Thanks to Prisma, it will also include tools for previewing and managing database changes.

We are building new functionality for handling images and files in Keystone. Initially this will mean support for local image and file uploads, and we have plans to expand this into native cloud hosting support as well.

As web developers, we all know how important accessibility is, but very few CMS UIs are truly accessible. We're changing that by baking first class accessibility into Keystone's Admin UI.

We're planning to revisit our field types and make them more powerful and consistent. This will include new interface options for the Admin UI, new features for validation and logic, and better null value handling.

If you have users who speak a languge other than English, you'll soon be able to provide a custom translation for all the strings in Keystone's Admin UI.

As your app outgrows the built-in CRUD queries and mutations that Keystone provides, we want the Admin UI to continue to be a comprehensive solution for your users. We're working on a framework that will let you extend the Admin UI with your own custom pages, React components, API route handlers and navigation - so you can make it your own.

When lists get complex, you want to break up the form into multiple sections of fields. Also, some fields depend on the value of others, and the form should update dynamically as item data is changed.

We're planning to design a way of defining this behaviour in your List Schema, so you can ship a better authoring experience out of the box.

Often when you're working with items, you want to allow content authors to manage nested repeating data. Relationships have traditionally been the answer for this, but come with complexity and can't be ordered.

So we're looking to add support for defining simplified nested schemas to lists, which will be stored in a JSON field in the database.

Keystone is great for lists of data, but sometimes you want a single object that is editable through the Admin UI and accessible in the GraphQL API. So we're planning to add the ability to define singletons in Keystone's Schema.

Ever wanted a list of items you can sort by dragging and dropping them in the Admin UI? We have.

And it will custom with custom mutations for handling ordering operations like insertBefore and insertAfter so it's just as easy for you to build your own UIs for sorting items in the list too.

If you're building a website with multi-language support, in Keystone 5 you'd have to add individual fields for each translation. To make for a better authoring experience, simpler schema definition, and streamlined experience for front-end developers we're planning to build first-class support for translated fields into Keystone.

Previewing content changes is a critical part of editing with confidence, but it's hard to implement consistently across sets of changes in a relational database backend.

Now that popular front-ends like Next.js have built-in support for live content previews, we're planning to develop an integrated workflow for Keystone content that will allow authors to preview sets of content changes in draft, and publish them atomically.

We're also looking at a built-in solution for tracking changes and version history.