A client rang me last October in a mild panic. They'd built their entire marketing platform on a hosted CMS and the vendor had just announced a pricing restructure. Overnight, their bill was going from £180/month to something north of £900. The content wasn't complex. A blog, a product catalogue, maybe forty custom fields across three collections. Nothing that justified that number. That call is the reason I spent the next three months moving two Seahawk projects to Payload CMS and building a proper cost model around it.
So let me tell you what I actually found.
What Payload CMS Actually Is (and Isn't)
Payload is a TypeScript-first, code-driven headless CMS. You define your collections, globals, and fields entirely in config files. No GUI to click around in for schema design. The admin panel is generated from your code, not the other way round. That inversion is the whole point, and it's also the thing that will trip you up if you're coming from WordPress or Contentful.
It's not a SaaS. There's no Payload-hosted tier you pay monthly for. You own the deployment entirely. That's a feature and a constraint depending on your situation.
Payload 2.0 shipped with full support for PostgreSQL alongside MongoDB, which was the unlock that made it genuinely viable for clients who want relational data without the NoSQL gymnastics. By early 2026, the ecosystem around it has matured enough that I'm comfortable recommending it for production without the caveats I used to attach.
What It's Actually Built On
Under the hood: Next.js 15 for the admin UI, TypeScript throughout, and your choice of Drizzle ORM (for Postgres) or Mongoose (for MongoDB). The REST and GraphQL APIs are auto-generated from your schema. You also get a local API for server-side queries that's fast in a way that still surprises me every time.
Where It Fits in 2026
Honestly, Payload sits in a specific sweet spot. Not every project belongs there. After running it on a dozen builds across Seahawk, here's the pattern I've noticed.
It's a strong fit when:
- The project is developer-led from the start. Meaning a real engineer is configuring it, not a client who's been told they can "manage everything themselves."
- You need custom field logic, conditional fields, or complex relationship chains that would cost you dearly in per-feature charges on something like Contentful.
- The client is cost-sensitive over a 2-3 year horizon. The maths almost always swing Payload's way after month 14.
- You're already running a Next.js or Node application and want the CMS co-located or at least sharing infrastructure.
It's a bad fit when:
- The client needs a non-technical person to set up new content types without engineering support.
- You're building something that needs to be handed off completely and the recipient has no developer on staff.
- Time to launch is under two weeks and you don't have a Payload project scaffold ready to clone.
I learned that second point the hard way. Back in 2022 I scoped a small charity site with Payload (v1 at the time). The plan was to hand it over to their in-house volunteer coordinator to manage. Three months later I was still fielding WhatsApp messages about why the field wasn't appearing. The CMS wasn't wrong for the project technically. It was wrong for the handoff model.
The Real Cost to Run Payload in 2026
This is the section most blog posts skip or dress up with vague ranges. Let me give you actual numbers from what I've run.
Infrastructure
You need somewhere to host the Node server and somewhere to store your database. Those are your two hard costs.
Option A: Railway I use Railway for most Payload projects under medium traffic. A typical Payload app (Node service + Postgres instance) runs between $12 and $35/month depending on usage. For a marketing site with editorial content, you're almost certainly in the $15-20 band. Deploys are straightforward from a GitHub repo, and the Postgres backups are automatic.
Option B: Render Similar pricing to Railway. Free tier exists but don't use it for production (cold starts will embarrass you in front of clients). Paid plans start at $7/month for the web service plus $7/month for the managed Postgres. So ~$14/month minimum, scaling with CPU and memory as traffic grows.
Option C: Self-managed VPS If you're running multiple Payload projects, a DigitalOcean or Hetzner VPS starts looking attractive. A Hetzner CX32 (4 vCPU, 8GB RAM) costs €8.29/month and can comfortably run three to four Payload instances behind an Nginx proxy. I run a shared Postgres instance on the same box for smaller clients. Not for the faint-hearted, but perfectly stable.
Media Storage
Payload doesn't handle your images for you unless you configure a storage adapter. The two I've used in production:
- AWS S3 + CloudFront for anything at scale. Budget roughly $5-15/month for a typical marketing site.
- Cloudflare R2 as S3-compatible storage with zero egress fees. This is my default now. For a site pushing ~50GB of media assets, I'm paying essentially nothing in egress and about $1.50/month in storage. Use the payload-cloud-storage plugin and point it at R2.
Developer Time (the cost people forget)
Initial setup of a Payload project, properly scaffolded with auth, media, the collections your client needs, and a sensible access control model: budget 12-20 hours for an experienced developer. That's not optional complexity, that's just the nature of a code-first CMS. On a day rate of £400-600 (London mid-market freelance), that's £4,800-12,000 upfront before you've written a line of frontend code.
Compare that to spinning up a Contentful space and configuring content types via their UI in 3 hours. The upfront cost is real. The ongoing cost is where Payload wins.
Total Cost of Ownership, Year 1 vs Year 3
Here's a rough model for a mid-sized marketing site, comparing Payload on Railway vs Contentful's Growth plan:
- Payload on Railway, Year 1: £18/month infra + ~£5,000 setup time = ~£5,216 total
- Payload on Railway, Year 3: £18/month infra + minimal maintenance = ~£648 infra across year 3
- Contentful Growth plan, Year 1: £320/month = £3,840, no custom setup cost
- Contentful Growth plan, Year 3: £320/month = £3,840 again
The crossover happens somewhere around month 20-22 depending on your day rate. After that, Payload is substantially cheaper. For a client who's going to be running the same site in 2028, this matters.
The Developer Experience in Honest Terms
I genuinely enjoy working in Payload. The config-as-code approach means your schema is version-controlled, reviewable in pull requests, and deployable like any other code change. That alone puts it ahead of CMS tools where a content modeller has been clicking around in a GUI and nobody actually knows what changed or when.
The TypeScript inference is excellent. Your collection types flow through to your local API queries without any manual type generation step. Seahawk had a fintech content project last year where we were querying deeply nested relationship data, and the type safety caught two data-shape bugs before they ever hit staging. That's not nothing.
The admin UI is clean and fast. Not flashy, just functional. Non-technical editors generally get comfortable with it within a session or two once the fields are well-labelled. Hooks are the other thing I want to flag: before-change, after-read, and similar lifecycle hooks let you do things at the data layer that you'd otherwise have to build custom API middleware for.
The Rough Edges
Migrations. If you're on Postgres and you change your schema, you need to run Drizzle migrations. This is fine if you know what you're doing and mildly terrifying if you don't. I've seen a junior dev on a Seahawk subcontract drop a column by not reading the migration diff carefully. Always review, always back up first.
The plugin ecosystem is smaller than WordPress, obviously. But the Payload plugin directory has grown meaningfully. Form builder, nested docs, SEO fields, redirects. The important bases are covered. You'll still write more custom code than you would on a more established platform.
How It Compares to the Other Headless Options
Let me be blunt about where I'd pick something else.
Sanity.io if your content team is large and non-technical editors are creating their own content structures. Sanity's Studio is friendlier for that audience, the hosted backend is reliable, and the GROQ query language is genuinely pleasant to write. You'll pay $99+/month on a real plan, but for some clients that's worth it.
Strapi was the Payload alternative for years. It's still viable and the self-hosted model is similar, but I find the TypeScript experience clunkier and the upgrade path between major versions has historically been painful. Payload's codebase feels more intentional to me.
WordPress with ACF or a block-based setup for anything that needs to be handed to a non-technical maintainer who's already comfortable with WordPress. Still the right answer for large swaths of what agencies build. Don't let anyone tell you otherwise.
Directus as a dark horse worth a look, especially if you're working with an existing database schema you need to wrap a CMS around. Different philosophy from Payload but genuinely good at that specific job.
FAQ
Is Payload CMS free to use?
Yes. Payload is open-source under the MIT licence. There's no licence fee. You pay for your own hosting infrastructure, which is the tradeoff versus a hosted SaaS CMS.
Can non-technical clients use Payload's admin panel?
With well-labelled fields, sensible defaults, and some basic training, yes. The admin UI is clean enough that editors pick it up reasonably fast. What they can't do is create new collections or change the schema without a developer. That's a hard constraint by design.
Does Payload work with Next.js?
Yes, and particularly well. Payload 2.x was rebuilt on Next.js, so you can run the CMS and your frontend from the same Next.js app. This "monorepo in a single repo" setup works well for small to mid-sized projects and reduces your infrastructure overhead.
What database should I use with Payload?
For new projects in 2026 I default to PostgreSQL via Drizzle ORM. It's well-tested, you get proper relational constraints, and the migration tooling is solid when used carefully. MongoDB remains an option and is still a good fit if your data is document-shaped by nature, but Postgres is my first recommendation.
How does Payload handle media uploads?
By default, Payload stores uploads locally on the server filesystem, which is fine for development but not production. For production you'll want to configure a storage adapter pointing at S3, Cloudflare R2, or similar. The official @payloadcms/plugin-cloud-storage package handles this and it takes about an hour to set up properly the first time.
Is Payload ready for large-scale production sites?
It's running serious production traffic at a number of companies. That said, it's not the CMS I'd pick for a site with 10 million monthly visitors and a 20-person editorial team. At that scale you'd be looking at enterprise-grade options with dedicated support contracts. For the agency-built, mid-market projects that make up most of our Seahawk work, Payload is stable and capable.
The Honest Takeaway
Payload CMS in 2026 is a mature, well-built tool for developer-led projects where long-term cost matters and you have the engineering capacity to own the stack. The initial investment in setup time is real. The ongoing infrastructure cost is low. The developer experience is good.
It's not a WordPress replacement. It's not trying to be. But for the right project, with the right team, it's the most cost-effective headless CMS option I've worked with across 12,000+ builds. The question isn't whether it's good. It's whether it's good for your situation.