Before talking about the future, I'm compelled to take a second and reflect on everything the Payload team and its community has just launched. I spent this past weekend decompressing and looking back on everything, and I'm intensely thankful to everyone that's helped push Payload so hard over the past few months.

There was so much more behind the scenes didn't get a spotlight. In addition to the launch day topics, Payload itself went through some significant changes, and we completed a ton of stuff from our roadmap. Here are a few examples:

JSON field
Dramatically improved TypeScript experience
Loading UI enhancements
Drawer UI
Refactored, more minimal Local API
Adding uploads within Rich Text
Document-specific access control reflected in UI
Tabs field now stores its "last accessed" tab in user preferences
Lots more

Add on the fact that we launched Payload Cloud, bulk operations, community help, serverless, and our ecommerce boilerplate. That's quite the quarter. And we're only ten people. Most all of our competitors have 100+ employees. What will our bandwidth look like as a team when we're 100+ employees?

Rewind ~6 months and the first thing I'd say I like about the "Launch Week" idea is that it helps you make an "event"—something that happens that your community can rally around. But ask me today, and I'll tell you something different.

In hindsight, it's clear to me that the biggest value comes from our team's self-imposed commitments to hit our deadlines and deliver on what we set off to do, when we set off to do it.

What's next

Well, not gonna lie, it's time to just take it easy for a few days. Maybe go outside. After that we're going to hit it hard again. The first thing we plan to do is to renew our focus on our community. Our goal will be to exponentially multiply our involvement in Discord / GitHub community help. We want to make sure that everyone that has a question finds an answer.

We're also going to begin introducing more programs for involving community voices more like Office Hours, Community Q&A, and more. But outside of the community initiatives themselves, we've got some big things on the radar.

Semantic versioning and LTS

I've been around the web for a while and have seen conversations where devs will make "concessions" about a product being open-source. A flawed mentality exists, stating that you should expect a certain amount of rough edges with OSS, and that it's inherent with a community-driven product. But I fundamentally disagree with that. Look at Red Hat or Postgres. People absolutely do not expect rough edges with those products.

One of the moves we're going to make here is to move to a true semantic versioning mentality. The team and I have been hesitant about marking breaking changes as a new major version, because we'd like our major versions to coincide with big, splashy releases. But that's not going to happen anymore. If there is a breaking change, there will be a major version bump.

That said, we're also going to maintain LTS (long-term support) versions for each major Payload version. So if you're an enterprise that comes onto Payload at a given major version, you can trust that security vulnerabilities and similar will be resolved on that major version, without having to update your product to the newest version instantly.

I'm going to hazard a guess that 2.0 will either arrive at the end of this quarter, or sooner, based on how we roll out changes. But the moral is that product trust and predictability is now officially more important than making big marketing splashes with major version bumps.

Additional database support

The most-upvoted feature on our roadmap as of now is to provide more support for additional databases. So that's up next. We're going to establish an adapter-based pattern for additional database support, likely starting with Postgres, but supporting more as time goes on.

Migrations

Once we have an adapter-based database pattern established, we will move on to first-party database migration functionality.

Make Sharp opt-in

With today's modern frontend ecosystem, image resizing generally happens with something like next-image - making it so Payload's forced use of Sharp might be completely unnecessary. Sharp is a big dependency. If we can establish an opt-in / adapter-style pattern, we can boost DX across the board for those that don't need it.

Replace Webpack

Goodbye, 2015. Keeping with our adapter-based thinking pattern above, we want to establish a way to use a more modern bundler for admin JS bundling. Could be Turbopack, could be Vite. Could be both if we do the adapter style pattern right. You'll still be able to use Webpack if you want, and we'll try to ensure that all of the functions that Webpack provides are available in the newer equivalents, but for new projects, you should be able to spring for a faster bundler.

Component library

We've got a lot of slick React components, but documentation is sparse and it's hard to know how to use them / where to import them from. We're going to fix that by building a fully supported and documented component library. This one will be huge.

Potential Slate replacement

Let's just keep this adapter talk going, shall we? Another thing we've got on the radar is to allow users to choose between Slate and another Rich Text library like Lexical. Alessio from our community has done some killer work building a plugin that swaps in Lexical instead of Slate and it looks very promising, so we're going to keep going down that path. This one might not be for Q2, but it might. One thing's for sure, we will definitely have more answers and we'd love your opinion.

The goal will be to end up with a preferred rich text editor, but we want to expose options for you to help us figure out which one is a better long-term option. You'll ideally be able to pass in which rich text editor you'd like your project to use on an adapter basis just like the above patterns.

Edge function support

This one's gonna be tough but I personally think there's a lot of value in it. If we can get our dependencies and core codebase small enough, we could easily deploy to edge functions, which would be a CMS first.

Cloud updates

Outside of Payload itself, we're going to be building more into Cloud. Email support, on-demand backups, managing multiple environments, usage screens, and more will all be coming up next.

Get started today

Just coming into Payload? There's never been a better time. You can get started with everything you need to run in production with Payload Cloud.

Create a new project