Technology
Payload CMS for Content-Rich Next.js Products
Payload is a CMS you deploy rather than subscribe to: TypeScript-native, running inside your Next.js application, with your content in your own database. This page is how we model, build and run it, including on this website.
- Payload 3
- Next.js native
- TypeScript
- Localisation
- Live preview
- Self-hosted
Reviewed by Bhavesh Selarka, COO & Co-Founder, Heliconia Solutions · Odoo 16 Functional Certification · Odoo Partner · Updated
Proof
Clients
Businesses that run on what we built
The short answer
What Is Payload CMS, and When Does It Fit?
Payload is an open-source, TypeScript-native headless CMS that runs inside your own Next.js application and stores content in your own MongoDB or Postgres database. It fits content-rich products that need real editorial workflow (drafts, versions, localisation, preview) without handing your content to a SaaS. It is less suitable for teams with no Node hosting and no appetite to run anything themselves.
The difference that matters in practice is ownership. Your collections are code, your content is in your database, and the admin ships with the application rather than a third-party service with its own pricing, rate limits and export format. If you've ever tried to leave a hosted CMS, that distinction is the whole argument.
We run it ourselves: the blog on this website is Payload 3 with drafts, autosave, versions, scheduled publishing, live preview and media on object storage. Everything described below is something we operate, not something we have only read about.
What we deliver
What We Build With Payload
Each item is running in a production system, with the project named.
Content modelling that survives growth
Collections, blocks and relationships designed around how the content is actually used. Freiburger Bund models news, community posts, jobs, learning material and a medical-journey section in one schema.
- Collections
- Blocks
- Relationships
Editorial workflow that editors trust
Drafts, autosave, version history with restore, and scheduled publishing. On this site every blog post has that workflow, and the public API only ever returns published documents.
- Drafts
- Versions
- Scheduled publish
Live preview of the real page
Editors see the actual front end rendering their draft, not an approximation. We wire it with a shared secret and a server-rendered preview route, so drafts never leak to search engines.
- Secret-gated
- noindex
- Real layout
Localisation done properly
Freiburger Bund publishes in German, English, French and Arabic, with automated translation extraction and sync, and a right-to-left language in the same system.
- Four languages
- RTL
- Translation sync
Media on object storage
Uploads go to S3-compatible storage (Cloudflare R2 on this site, AWS S3 and MinIO elsewhere) with named renditions generated on upload, so the front end can ship the right size.
- R2 / S3
- Renditions
- Streamed delivery
Publishing that reaches a static site
A prerendered front end does not change when an editor publishes. We close that with a webhook: publish fires a secret-gated rebuild, so editors see their change without anyone running a deploy.
- Webhook
- Rebuild
- No manual deploy
The pattern
How a Payload System Fits Together
Payload runs as its own deployment next to the site it serves. The front end reads published content over REST or GraphQL, and nothing else talks to the content database.
- Payload 3
- Next.js
- TypeScript
- MongoDB
- PostgreSQL
- S3-compatible storage
- GraphQL
- REST
Editors
The Payload admin, shipped with the application, with roles and access rules.
The website or app
Next.js, Astro or a mobile client reading published content over the API.
Other systems
Search indexes, notification services and the ERP where content and operations meet.
Payload application
Collections, access control, hooks and the admin UI, deployed as a Node application on your infrastructure.
Content API
REST and GraphQL, returning only published documents to anonymous callers, with a secret-gated endpoint for the draft the preview route needs.
Database and media
MongoDB or Postgres for documents, S3-compatible object storage for uploads, both in accounts you own.
Front end
The site or app that renders it, built separately so a content change never requires a front-end release and vice versa.
Honest positions
When We Recommend Payload, and When We Do Not
A CMS choice is a ten-year decision for the content inside it. These are the calls we make.
| Your situation | What we would recommend | Why |
|---|---|---|
| A Next.js product with real editorial needs | Payload | It runs inside the app, the schema is code, and drafts, versions and localisation are built in |
| Content must stay in your own infrastructure | Payload | Your database, your object storage, your deployment. No vendor holds the content |
| Marketing needs a page builder and nobody will maintain a deployment | A hosted CMS | If there is no one to run a Node app and a database, self-hosting is a cost you will feel later |
| The content already lives in an ERP or PIM | Keep it there and read it over the API | Two systems owning the same records is the most expensive CMS mistake we see |
| A WordPress site with a working editorial team | Probably stay, or go headless with what you have | Replatforming a CMS that works buys you engineering satisfaction, not business value |
We also build on Odoo’s own website tools and on WooCommerce and Shopify. The recommendation follows the system and the team, not our preference.
How we work
Migration, Versions, Access and Operations
- Content migration from the existing CMS, mapped field by field, with a dry run against a copy before anything is written
- Access control designed per role: who can create, who can publish, who can see unpublished work, enforced by the API rather than by the admin UI alone
- Generated TypeScript types shared with the front end, so a schema change breaks the build rather than the website
- Versioned deployments with the same rollback path as the rest of the stack, and the database on managed hosting where that is sensible
- Search wired to a real engine when the content warrants it, as with MeiliSearch on the Freiburger Bund portal
- Upgrade policy: Payload and Next.js majors planned as work, because a CMS that is three versions behind is a security problem, not a stable one
- Documentation and admin training for the editors, because a CMS nobody enjoys using quietly stops being used
Evidence
Payload Systems We Run
Two client systems, plus this website, which is the one you can inspect right now.
| Project | Industry | Odoo | Key capabilities | Technology |
|---|---|---|---|---|
| Freiburger Bund | Healthcare association & career portal | Odoo 18 Enterprise | Freiburger Base · Freiburger Community Portal · Freiburger Info & News Portal · Freiburger Job Portal | Odoo 18 Enterprise · Python · PostgreSQL · Next.js 15 · React 19 |
| LittleQ | eCommerce, baby care | Odoo | Headless Odoo API · Product Catalog Management · Product Discount Engine · Distributor Registration Portal | Odoo · Next.js · PayloadCMS · React · Node.js |
First-party proof
This Website Runs on Payload
- 01
The blog you can read on this site is served from Payload 3 on Next 16: posts, categories, tags, media and authors, with the public API returning published documents only.
- 02
Editors get drafts, autosave, version history with restore and scheduled publishing, and a live preview that renders the real article layout behind a shared secret.
- 03
Media lives on Cloudflare R2 with named renditions, and the front end re-encodes each image to WebP with a srcset at build time.
- 04
Publishing calls a secret-gated webhook that triggers a rebuild of the static site, so an editor never waits for a developer to deploy.
- 05
We did this before recommending it to clients, which is the only reason the operational detail above is specific rather than aspirational.
What clients say
In Their Words
Heliconia transformed our business with Odoo. They implemented a dynamic website with e-commerce capabilities, enhancing our online presence significantly.
Sandesh ThummarBusiness Owner, Ladder LogixHeliconia provided a unique canteen solution, saving us valuable ordering time. Their innovative approach has been invaluable to our operations.
Pradeep LakhaniBusiness Owner, Avasar Agency
Questions
Payload CMS Questions, Answered Directly
Is Payload CMS free?
The CMS is open source and free to self-host, which is how we deploy it. You pay for hosting, the database and object storage, plus the work to build and run it. Payload also sells a managed cloud option if you would rather not operate it.
How is Payload different from Strapi, Directus or Contentful?
The short version: Payload is TypeScript-native and runs inside your Next.js application rather than beside it, with the schema defined in code. Contentful is a hosted service you subscribe to. Strapi and Directus are self-hostable too, with different modelling philosophies.
We have run Payload in production and have not shipped Strapi or Directus, so we will not pretend to an equal comparison. When we publish those comparisons they will say the same thing.
Can editors see their changes before publishing?
Yes. We wire live preview so the admin renders the real front-end page for the current draft, gated by a shared secret and marked noindex so an unpublished page can never be crawled. This site works exactly that way.
Does Payload handle multiple languages?
Yes, including right-to-left. Freiburger Bund publishes in German, English, French and Arabic from one Payload instance, with automated translation extraction and sync between the CMS and the application.
Can Payload sit in front of Odoo?
They sit side by side rather than one in front of the other, and that is the right model. Payload owns editorial content. Odoo owns products, stock, orders and customers. The front end reads both.
Freiburger Bund and LittleQ both run that split in production.
What happens when Payload releases a new major version?
We plan it as work. Majors bring breaking changes, so we upgrade on a copy first, run the content through it, and schedule the switch. The cost of staying current is far lower than the cost of a rescue upgrade two years later.
Next step
Model the Content Before You Pick the CMS
Tell us what you publish, who edits it, how many languages and where it has to appear. We will propose a content model and an honest recommendation, including when a hosted CMS or staying put is the better answer.