# Deploy Payload CMS on Kuberns With a Managed Database
> Deploy Payload CMS without breaking the admin panel or losing data. See exactly what it needs to run and how to launch it on Kuberns in a few steps with ai.
- **Author**: parth-kanpariya
- **Published**: 2026-08-29
- **Modified**: 2026-08-29
- **Category**: Deployment Guides
- **URL**: https://kuberns.com/blogs/deploy-payload-cms/
---
Payload CMS needs a real Node.js server running at all times, not static hosting, because its admin panel and API routes execute server-side on every request. It also needs a Postgres or MongoDB database, S3-compatible object storage for uploaded media, and migrations that run automatically on deploy rather than by hand. For a client project, the platform that actually works is one that provisions that database for you and runs migrations on deploy, not a JAMstack host built for static or edge-only sites.
Deploy Payload the same way you would a plain marketing site, and the build succeeds, but the admin panel throws a 500 error the moment someone tries to log in, because there is no persistent server behind it. This is the exact wall agencies and freelancers hit when a client project moves from local development to a live URL, and it shows up constantly in Payload's own community, not as a one-off mistake.
This guide covers what Payload actually needs to run, where agencies and freelancers keep getting stuck deploying it for clients, how the hosting options compare, and how to deploy Payload CMS on Kuberns for a client project without stitching together three separate vendor accounts.
## TL;DR
- Payload needs a real Node.js runtime, a Postgres or MongoDB database, S3-compatible storage for media, and migrations wired to run on deploy, not a static or JAMstack host.
- Deploying Payload like a plain static Next.js site is the most common mistake agencies make. The build succeeds, but the `/admin` panel and API routes fail with server errors.
- For price-sensitive client budgets, the real cost driver usually isn't the CMS itself, it's stitching together a separate database vendor, storage vendor, and hosting vendor for every client site.
- Payload's own co-founder has said outright that hosting a CMS is meaningfully more complex than hosting a static site, so the vendor-sprawl problem agencies run into is real, not something they're imagining.
- Kuberns runs a [managed PostgreSQL or MongoDB datastore](https://kuberns.com/blogs/best-managed-postgresql-hosting/) alongside your app, so a client project needs one dashboard instead of four separate accounts.
## What Payload CMS Actually Needs to Run in Production
### A Real Node.js Server, Not Static Hosting
Payload is not a static site generator. Its admin panel, authentication, and REST and GraphQL APIs all run server-side, on every request, which means it needs a platform that keeps a Node.js process running rather than one that only serves pre-built HTML files.
One developer building their first Payload site for a hockey team described exactly this trap on r/PayloadCMS: the app built and deployed fine, but only the static pages worked, `/admin` returned a 500 server error, and every API call on the dynamic pages failed. Nothing was wrong with their Payload project. They had deployed it to a platform that only ran the static output, not the server behind it.
### A Postgres or MongoDB Database
Payload stores content, users, and relationships in either Postgres or MongoDB, chosen when the project is set up. There is no lightweight, file-based option for production, so a client deployment needs a real managed database running somewhere before the CMS does anything at all. A developer setting up their first Payload app on r/PayloadCMS put the problem plainly: they weren't sure if Vercel was a bad idea given its serverless architecture, and they wanted something with a [managed Postgres database](https://kuberns.com/blogs/best-managed-postgresql-hosting/) and object storage included, without having to become a DevOps expert first.
### S3-Compatible Storage for Media Uploads
Uploaded media, images, PDFs, anything an editor adds through the admin panel, needs to live in S3-compatible object storage rather than the app's local disk. A container's local disk gets rebuilt on every deploy, so anything written there during the app's life does not survive the next one. This is a separate service from the database, and on most platforms, a separate account and bill.
### Migrations That Run on Deploy, Not by Hand
Payload's schema changes as your content model evolves, and those changes need to run as migrations against your database on every deploy, not as a manual step someone remembers to run. A practitioner deploying Payload to Fly.io wrote up exactly how much this trips people up: getting migrations to run automatically during production startup, rather than manually after the fact, was the single hardest part of the whole deployment, on top of standing up Postgres, the Payload app, and a search service as three separate pieces.
## The Deployment Mistakes That Trip Agencies and Freelancers Up
### "Can I Just Deploy Payload to Vercel or Netlify Like Any Next.js App?"
This is the single most common question in Payload's own community, and the honest answer is: not the same way you'd deploy a plain Next.js marketing site. Vercel's serverless functions can run Payload with the right storage adapter, but you're still responsible for a separate managed database and separate object storage, they don't come with the platform. Netlify is worse for this specific case: its default deploy only serves static output, which is exactly why the frontend developer above ended up with a broken `/admin` panel and failing API calls, their app looked deployed but had no server behind the dynamic parts of the site.
### What to Do When a Client Won't Pay for Vercel, Neon, or Supabase
Not every client market defaults to the same stack assumptions. One agency owner building Payload sites for clients in Europe laid out the problem on r/PayloadCMS: their market is used to WordPress and simple shared hosting, not Vercel, Cloudflare, Neon, or Supabase, and asking a price-sensitive client to create and hand over access to a Supabase account felt like the wrong repeatable setup. A VPS was ruled out too, since it meant being effectively on call for every client site.
That tension, cheap and simple versus something you can actually support, shows up constantly in Payload's own community threads. One developer comparing database options for a DigitalOcean deployment found MongoDB Atlas running about $57 a month for 10GB against DigitalOcean's own managed database at roughly $15 a month for 15GB, with self-hosting inside a Droplet sitting somewhere between free and "a hassle to set up." None of those numbers are wrong, they're just the real cost of assembling a database, storage, and hosting from three separate vendors for every client project.
### What Happens When Nobody's Watching the Server
Hosting a CMS is not a set-it-and-forget-it job the way a static site is. One team running Payload in production reported pages taking up to 20 seconds to load, with the server's CPU maxed out under just 10 simultaneous users, a problem eventually traced to their specific configuration rather than Payload itself, but one that took real production traffic to surface.
Payload's own co-founder made a version of this same point when the product launched: "Hosting a CMS is quite a bit more complicated than a static site," pointing out that most people who self-host a static Next.js app never have to think about a database or persistent file storage, and a CMS forces both questions immediately.
## Comparing Where Agencies Actually Deploy Payload
Community threads on this converge on roughly the same short list. Payload Cloud, the CMS's own official platform, is the path of least setup if you're comfortable paying for that convenience and don't need infrastructure to live alongside other client apps.
A self-managed VPS running Coolify came up repeatedly in Payload's own "best place to deploy" community thread as the cheapest option, with one user citing roughly $5 a month for a 2GB, 2vCPU box, but it puts you on the hook for updates, backups, and uptime yourself. DigitalOcean's App Platform got called out in the same thread as feeling "very similar to deploying on Vercel," with automatic deploys from GitHub and comparatively little configuration.
For an agency running more than one client project, the deciding factor usually isn't the sticker price of any single option, it's whether the platform also hands you a managed database and backups, or leaves you to bolt those on separately for every new client site. If Payload isn't a fit for a given client and you're weighing other headless options, [Strapi deploys the same way on Kuberns](https://kuberns.com/blogs/deploy-strapi-in-one-click-with-ai/), with a managed database included.
## How to Deploy Payload CMS on Kuberns for a Client Project
### Connect Your GitHub Repository
Push your Payload project to GitHub and connect the repository to Kuberns, selecting the branch you want deployed.
### Create a Managed Postgres or MongoDB Datastore From the Resources Tab
Inside your Kuberns environment, open the Resources tab and create a Postgres or MongoDB datastore, matching whichever database your Payload project is configured for. It appears under Datastores in the platform navigation, with its own Overview, Metrics, Backups, and Settings pages.
### Set Environment Variables and Deploy
Pull the database name, username, password, and hostname from the datastore's Overview page and set them, along with `PAYLOAD_SECRET` and your S3-compatible storage credentials, as [environment variables in Kuberns](https://kuberns.com/blogs/environment-variables-in-production/) rather than hardcoding them. Deploy, and Payload runs against a real Node.js server with a managed database behind it, the same setup a static-only host can't give you. Turn on automatic backups from the datastore's Backups page while you're there.
## Who Should Own the Hosting for a Client Project
Once Payload is actually running somewhere, the next question is usually whose account it should run under, the agency's or the client's. That's its own decision with real implications for billing and handoff, and it's one we've already covered in detail in [how agencies can centralize client apps and increase profits](https://kuberns.com/blogs/manage-client-app-deployments/), rather than repeating it here.
## Ready to Deploy Payload CMS Without the Guesswork?
Every real problem in this guide traces back to the same root cause: Payload needs a server, a database, and object storage working together, and most hosting options only give you one or two of those out of the box. That's what turns a client project into a stack of separate vendor accounts, a database bill here, a storage bill there, a hosting bill somewhere else, each with its own login and its own thing that can break.
Kuberns runs your Payload app and its managed Postgres or MongoDB datastore in the same project, with connection details, backups, and monitoring in one dashboard. Connect your repo, create the datastore from the Resources tab, set your environment variables, and deploy, without asking a price-sensitive client to hand over a Supabase login or leaving a VPS for you to babysit at 2am.
[Deploy your next Payload CMS project on Kuberns](https://dashboard.kuberns.com/)
## Frequently Asked Questions
### Can I deploy Payload CMS to Vercel or Netlify?
You can get it to build, but a plain static or JAMstack deploy will break Payload's admin panel and API routes, since both need a persistent Node.js server rather than pre-rendered pages. Vercel's serverless functions can run Payload with the right adapter, but you still need a separate managed database and object storage wired in yourself. Netlify's default static deploy does not run Payload's server at all, which is why the admin panel returns a 500 error the moment someone tries to log in.
### Does Payload CMS need MongoDB or Postgres?
Yes. Payload stores your content, users, and relationships in either MongoDB or Postgres, and you choose one when you set up the project. There is no built-in file-based database option for production use, so a client deployment needs a managed database running somewhere before the CMS itself works.
### Why does my Payload admin panel show a 500 error after deploying?
This almost always means the platform only ran Payload's static build output and never started its Node.js server, so requests to /admin and the API routes have nothing to respond to them. It can also happen when the database connection string or PAYLOAD_SECRET was never set as an environment variable on the platform you deployed to.
### How much does it cost to host Payload CMS for a client project?
Costs vary widely depending on how you piece it together. A managed database alone can run anywhere from about $15 to $57 a month depending on the provider and storage tier, before you add compute for the app itself or object storage for media. Platforms that run the app and provision the database together, like Kuberns, cut that down to one bill instead of stitching together a database vendor, a storage vendor, and a hosting vendor separately for every client site.
### Can one database serve multiple client Payload sites?
Technically yes, if you separate each client's data by database name or schema, but most agencies keep one managed datastore per client project instead. It keeps billing, backups, and data ownership clean if a client ever wants to take their project elsewhere, and it avoids one client's traffic or a bad migration affecting another client's data.
### Where do agencies usually host Payload CMS for client sites?
It splits a few ways: Payload Cloud for teams that want the CMS's own team to run infrastructure, a self-managed VPS with Coolify for agencies comfortable owning DevOps, or a managed platform that provisions the database and runs migrations for you. Community discussion around this consistently comes back to the same tradeoff, cheaper self-hosting costs more setup and on-call time, while a managed platform costs a bit more but removes the vendor-juggling.
---
- [More Deployment Guides articles](https://kuberns.com/blogs/category/deployment-guides/1/)
- [All articles](https://kuberns.com/blogs/)