Payload CMS hosting: how to choose where to run your project

Your Payload project runs well on your laptop, and now it needs a home. As of October 2026, Payload’s own notice says “deployment of new projects is currently paused”, so every new project picks its own host.

This guide covers what Payload needs besides a server, the one decision that sorts every hosting option, the four main routes, how to choose between them, and what to set up before you go live. It’s written from how we build on Payload. As of September 2026, we manage 27 Payload codebases, all built on Next.js, and we run them across Vercel, Cloudflare and private VPSs, among other hosts.

• What does Payload need to run?
• The one decision: serverless or a long-running server
• Four ways to host Payload
• Which one should you choose?
• What to set up before you go live
• What about Payload Cloud?
• Payload hosting: common questions
• What to do next

What does Payload need to run?

Payload needs a host that can run a Next.js app on Node.js 20.9.0 or later. Since version 3, Payload runs inside Next.js, so building it is the normal next build and running it is next start or your platform’s equivalent. Payload’s deployment docs say it can be deployed anywhere Next.js runs, and name Vercel, Netlify, SST, DigitalOcean and AWS.

Every production Payload project also needs five things besides the server:

• A database. Postgres, MongoDB or SQLite. Payload’s own templates use Neon for Postgres and Cloudflare’s D1 for SQLite.
• Somewhere permanent for uploads. Object storage such as Amazon S3, Cloudflare R2 or Vercel Blob, connected through a storage adapter.
• An email provider, for password resets and any emails your project sends.
• A CDN, so images and pages reach readers quickly.
• Environment variables, at least PAYLOAD_SECRET and DATABASE_URL, set on the host rather than in the repository.

For example, Payload’s official Vercel template bundles Vercel Blob for media and a Neon database, and its Cloudflare template bundles R2 and D1. The host you pick decides which of these pieces come with it and which you add yourself.

The one decision: serverless or a long-running server

The decision that matters most is whether Payload runs as serverless functions or as a server that starts once and stays up. Serverless hosts, such as Vercel, Netlify and Cloudflare Workers, start Payload when a request arrives and stop it when traffic dies down. A long-running server, such as a VPS or a container platform, boots Payload once and keeps it running.

Payload’s documentation treats the two differently for background jobs, database migrations and uploaded files, and those three decide which host fits your project.

Payload’s queue docs say autoRun “is intended for use with a dedicated server that is always running, and should not be used on serverless platforms like Vercel”. So a project that sends scheduled emails or syncs stock overnight needs a scheduled trigger on serverless hosts.

The migrations docs warn that running migrations at start-up “may slow down serverless cold starts on platforms such as Vercel”, so on serverless the build step runs them. Our guide to Payload migrations covers how the migrate commands work.

For uploads, the deployment docs name Heroku and DigitalOcean Apps as hosts with ephemeral filesystems, where “your uploads will accidentally disappear” after a restart unless they go to a storage provider.

Four ways to host Payload

Every hosting option for Payload falls into one of four routes:

1. Vercel, serverless, with an official template
2. Cloudflare Workers, serverless at the edge, with an official template
3. A VPS with Docker, long-running, on a server you manage
4. Managed containers, long-running, on a platform that manages the server

To keep the comparison concrete, each route is tested against three project shapes. Shape A is a marketing site with a blog and a few edits a week. Shape B is a store with daily editors and scheduled jobs, such as order emails and a nightly stock sync. Shape C is one Payload serving several brands’ sites.

Vercel

Payload’s official Vercel template deploys in one step with its storage and database already wired, which covers shape A as it stands.

On Vercel, you add two things yourself. Background jobs need a cron schedule in vercel.json that hits Payload’s jobs endpoint, as the queue docs show. Migrations go into the build script, for example payload migrate && pnpm build. Shape B works on Vercel with both in place, as long as each job finishes inside the maximum duration Vercel sets for a function on your plan.

The admin panel starts from cold after a quiet spell, so the first click after a pause can take a moment longer, a few seconds at most in our experience. We run Payload builds on Vercel. What Vercel costs per month, from our own invoice, is on our Payload pricing page.

Cloudflare Workers

Payload’s Cloudflare template runs on Workers with D1, Cloudflare’s SQLite database, and R2 for media, and it’s the lowest running cost on paper for shape A.

Payload’s own pull request #17397 records the template’s Worker bundle at 3,364 KiB against the free plan’s 3 MiB limit, so it fails to deploy on the free plan. The template’s README says it “can only be deployed on Paid Workers right now”, and as of 2 October 2026 that pull request is still open. D1 is SQLite, so a project moving from Postgres changes its database adapter and its migrations. The same README lists GraphQL as a known issue, with full support “not currently guaranteed” on Workers, so check it if your front end queries GraphQL.

We run Payload builds on Cloudflare too.

A VPS with Docker

A virtual private server runs Payload the way it runs on your laptop, as one long-running Node.js process. Hetzner, DigitalOcean Droplets and Amazon EC2 are common choices. Payload’s deployment docs include a multi-stage Dockerfile for production, with output: 'standalone' in the Next.js config to keep the image small. Their Docker Compose example is for local development, so a production Compose file runs the built image instead. If your pages read from Payload at build time, next build needs a database connection, and Payload’s guide to building without one shows the compile-only build mode that avoids it.

Everything in the long-running column works as documented. Jobs run with autoRun or as a separate payload jobs:run process, and migrations run at start-up with prodMigrations. That makes a VPS the natural fit for shape B, and for shape C when one deployment serves several sites.

In exchange, you run the server. TLS certificates, backups, operating system updates and the deploy pipeline are yours. Files written inside a container are lost when it’s recreated, so mount a Docker volume for uploads or use a storage adapter. Tools such as Coolify, CapRover and Dokku add a deploy button and certificates on top of your own server, which closes much of that gap. We run Payload builds on private VPSs as well.

Managed containers

A managed container platform gives you a long-running process without managing the server. Railway, Render, Fly.io, Google Cloud Run and DigitalOcean App Platform all run a Payload container from your repository or a Dockerfile and handle certificates and deploys. We run Payload builds on Railway too.

Keep in mind that some of these platforms reset the filesystem on every deploy or restart. Payload’s docs name DigitalOcean Apps as one, so use a storage adapter for uploads on any of them. For example, Payload’s case study of Viking Yoga describes a studio site and booking app running on Google Cloud Run.

Which one should you choose?

How the project behaves day to day matters more than how much traffic you expect. Four questions settle it:

1. How often do editors work in the admin? A few edits a week suits serverless. Editors working in it all day suit a long-running server.
2. Does the project run background jobs? Short, scheduled jobs work on serverless with a cron trigger. Long or frequent jobs belong on a long-running server.
3. How many projects and environments will you run? Each preview or staging environment usually gets its own database, so decide your environment plan before you pick a database provider.
4. Must the data stay in a region? Pick a host and database region in that market, for example in the EU or the UAE, and check the storage bucket’s region too.

For example, shape A, the marketing site, answers “rarely, no, one or two, no”, and Vercel or Cloudflare fits. Shape B, the store, answers “daily, yes”, and a VPS or a managed container is the simpler home, though Vercel with Cron works if the jobs are short. Shape C can run as one long-running deployment with Payload’s multi-tenant plugin, or as one deployment per brand on any route.

No single route wins for every project. We run builds on all four routes. Once you have a shortlist, compare what each route costs per month before you commit.

What to set up before you go live

Whichever route you choose, the launch list is the same. Work through it on a staging copy first:

1. Set a long, random PAYLOAD_SECRET and every other environment variable on the host.
2. Connect the production database and turn on backups.
3. Wire migrations into the build step on serverless, or into prodMigrations on a long-running server.
4. Add a storage adapter for uploads, unless they sit on a persistent, backed-up disk or Docker volume.
5. Schedule background jobs for your runtime, with Vercel Cron or jobs:run.
6. Serve the site over SSL and enable secure cookies on your auth collections, as the deployment docs recommend.
7. Re-test access control while logged in as a non-admin user.
8. Decide your staging and preview environments, and the databases they need.
9. Add a health check and readable logs, so a failed deploy shows up before your editors notice.

If you’d rather a team set up and maintain the deployment, our Payload CMS development work covers deployment to your own accounts, training and support.

What about Payload Cloud?

Payload Cloud has paused new projects. Payload’s notice reads “Although deployment of new projects is currently paused, existing Cloud projects will continue running as normal.” It gives no date for anything new.

Payload Enterprise is sold under an Enterprise licence and, per the get-started page, can be deployed “self-hosted or with Payload”. For everyone else, the four routes above are the options.

What to do next

Start with the runtime. Look at how often your editors work in the admin and whether the project runs background jobs, and pick serverless or a long-running server from that. Then choose the route that fits your project’s shape, wire migrations, uploads and jobs for that runtime, and work through the launch list on a staging copy before you point the domain at it.

For the platform-specific steps, Payload’s deployment docs are the place to start.

References

• Production Deployment, Payload documentation
• Queues, Payload documentation
• Migrations, Payload documentation
• Get started with Payload
• Reduce with-cloudflare-d1 Worker bundle for free-tier 3 MiB limit, PR #17397, payloadcms/payload
• Viking Yoga case study, Payload
• Payload has joined Figma, Payload
• with-cloudflare-d1 template README, payloadcms/payload
• Storage adapters, Payload documentation
• Functions limitations, Vercel documentation
• Building without a DB connection, Payload documentation
• Volumes, Docker documentation
• Hetzner
• Coolify
• CapRover
• Dokku
• Railway
• Render
• Fly.io
• Google Cloud Run
• DigitalOcean App Platform

All links checked and active as of 2 October 2026.