If you browse through our Discord community help forums, a big slice of the questions people ask are around deployment-related issues.
We want to make it easier for those of you that don't want to deal with that racket (me included). Of course, Payload will always be open-source and able to be self-hosted, but starting today, you've got a better option.
Today, we're launching the public beta of Payload Cloud. It's a deployment platform that works just like Vercel, but for regular Mongo + Express apps that run a server. Connect your GitHub repo and boom — we deploy everything you need for production instantly. It's not a SaaS CMS — instead, it's your CMS, deployed for you. We just give you the plumbing.
Every piece of infrastructure that we deploy — database, S3 storage, compute, email — is exposed to you, and you can do with it what you need. We just make it easy and tailor the experience to CMS-related expectations. No more vendor hell.
We are releasing Cloud as a beta, and that means you get everything for free until July 1. We'll foot the infrastructure bills for you until then in exchange for you helping us ensure our infrastructure is solid.
Even on the smallest Standard tier, we've done the hard stuff for you. Out of the box, you get the following:
Your app will sit behind Cloudflare which means that you get everything that Cloudflare provides, like DDoS protection, automatic SSL certificates, a global CDN with caching, and custom domain support.
We've worked tirelessly with Cloudflare to even allow you to use apex domains, which is rare.
I should take a second here to shine some light on this.
Have you ever tried to deploy an app to Heroku or DigitalOcean's App Platform on your root domain? Let's say, example.com
- NOT a sudomain like www.example.com
. With most DNS providers, you can't. That's because example.com
is an "apex" domain, and with most DNS providers, you need to point your apex domain to a static IP like a DigitalOcean droplet. So you're forced to jump through all sorts of hoops or just make a compromise.
But with Payload Cloud, we've configured our Cloudflare implementation with static IP support — so if you want to deploy your CMS and your frontend together, and host it directly on an apex domain, Payload Cloud gives you a static IP to point your domain to.
We work closely with Mongo and have partnered with them to automatically provision a database for you, running on Atlas. Payload Cloud allows you to rely on the Atlas platform's speed, stability, and scale instantly. Your database is yours. We give you the credentials. Do with it what you will.
Store your files on S3 with your own bucket access. Among other things, the new @payloadcms/plugin-cloud
package will handle storing all of your files on S3 seamlessly for you when deployed to Payload Cloud. As with MongoDB Atlas, we give you the creds, and you can do what you want with your files. They're yours.
No more pm2
. No more push / pull to a DigitalOcean droplet. Just connect your repo, and automatically deploy your code on push. Manage environment variables, monitor runtime logs, and more completely out of the box.
I have a theory about the state and future of headless CMS. The "headless" concept came about because people wanted to bring their own frontend. Of course, the omnichannel content aspect of headless is great, but let's not kid ourselves—many of you are just powering the content for a single website / app.
That's the funny thing about web development—the whole ecosystem is like a pendulum. It swings back and forth from complexity to simplicity and right now I think we're swinging back to simplicity.
If the majority of us are all just powering websites with headless CMS, how about we allow ourselves to combine the frontend and backend again? The CMS can still be API-based and "headless", but if we could combine the two, we can regain some of the seamlessness that we had with monolithic solutions. It's more "composable" than "headless".
That would allow us to once again do stuff like:
Build more efficiently and get our jobs done with less effort
Deploy updates to the CMS and the frontend in tandem with each other
More easily manage environments and feature sets
Share TS interfaces from backend to frontend without having a third shared utils
NPM package or similar
Build a better admin UX between frontend and backend using things like showing an "admin bar" while the user is logged in and browsing the frontend
One of the coolest parts about Payload Cloud is that if you want, you can deploy your entire stack (CMS and frontend) directly on one service. You no longer need to deploy your CMS separately from your frontend if you don't want to. This can be huge for cases where you, as engineers, want to simplify and work as efficiently as possible.
At its core, Payload Cloud is built to deploy Express + Mongo apps. Nothing more. So that means you can combine your Next + Payload apps directly in one and deploy it once. Put Remix and Payload in the same server. Run Sveltekit and Payload next to each other. Roll your own React frontend with Vite and deploy it seamlessly next to Payload.
Make your job easier. There are lots of possibilities here.
Through the rest of this week, we've got more announcements that make Payload able to be "composed" within your other apps, but this is definitely one of the side-effects of Payload Cloud that I'm most excited about.
This is the very beginning for Payload Cloud. Over the next few months until our exit from public Beta on July 1, we've got lots more coming.
First up, we want to launch our free tier. To do so, we need to keep working on how to reduce our own cost for this, because surprise surprise, there is no free lunch. Someone's paying for free stuff and it's gonna be us. We're happy to do so, because we want to make the developer experience for Payload as beautiful as possible. But we need to make sure that this is scalable and affordable, so we're going to try and revisit this as soon as we can.
We're working with Resend to give you a full, modern email service for every Cloud installation. This is almost done and will be a fast-follow to our beta launch today.
We want give you a way to utilize Cloudflare's CDN for everything, programmatically, across your app + frontend. Even Payload API responses. In the future, the @payloadcms/plugin-cloud
package will automatically cache all applicable API responses, and will dynamically invalidate CDN cache when documents change. We'll also be exposing a way for you, as a developer, to programmatically purge CDN cache as you need.
Right now, MongoDB Atlas manages automated backups for you, so backups do exist out of the box already today. But we want to expose them to you via our UI, to allow you to manage and create your own backups at your discretion. We also want to extend the "backup" idea to connect to files as well, so that when you take a backup, or one is scheduled, we give you a tidy little package containing your DB and your files, ready to go for use somewhere else.
We're going to be releasing a full suite of environment management controls that will allow you to sync your DB and your files from project to project seamlessly. That will allow you to build multiple environments like dev
, stage
, and prod
, while being able to seamlessly migrate files + data from one environment to another.
We have usage monitoring and reporting on our side, but we want to build this into the admin UI so that you can be informed of your usage in a simple and consistent manner directly within the Payload Cloud UI.
Over time, Payload Cloud will continue to evolve to be the best way to deploy Express + Mongo apps. It's only going to get better from here, and we need your help in making it so.