By Mehdi HassanHow do you set up Payload CMS for a marketing site?
You set up Payload CMS for a marketing site by adding it to a Next.js project, defining your content as collections and globals, configuring access and roles, and deploying the app with a database and file storage. Payload's admin panel and APIs then live at routes inside the same app.
This walkthrough is based on how we built our own site, designify.design, with Next.js, Payload and Cloudflare Workers. It's a description of decisions and setup, not a client case study, and it reports no traffic or performance results. Where we describe how we'd apply it for a client, that example is illustrative. For where Payload fits among your options, see our hub on CMS setup for marketing websites.
Why choose Payload for a marketing site?
We chose Payload because it's open source, written in TypeScript, and installs directly into a Next.js app, so the website and the CMS are one codebase with one deploy. Content types are defined in code, which means they're versioned, reviewed and typed like everything else.
Pros
- Site and CMS ship together, with no separate CMS vendor account
- Content schema lives in code with generated TypeScript types
- Access control is plain functions, so roles can be exactly as strict as you need
- The Local API reads content on the server without a network round trip
Cons
- You host and maintain it, including database migrations
- Upgrades touch both the CMS and the site at once
- Non-standard hosts, like Workers, need extra setup and some patching
- Editors' experience depends on what you build into the admin
If nobody on your team will own a codebase, a hosted headless CMS or a visual builder is usually the safer call. Payload suits teams with a developer, or a studio on retainer, who will keep it healthy.
How should you model collections and globals?
Model anything you have many of as a collection and anything that exists once as a global. On our site, projects, testimonials, client logos, team members, media, blog posts and bookings are collections. Site settings, the home page, pricing and the FAQ are globals, so editors can change that copy without touching code.
Content | Type | Why |
|---|---|---|
Projects and case studies | Collection | Many entries, each with its own page |
Testimonials | Collection | Reused on project pages and the home page |
Blog posts | Collection with drafts | Written and reviewed before publishing |
Pricing plans | Global | One set of plans shown in one place |
FAQ | Global | One list, also output as FAQ schema |
Site settings | Global, admins only | Email, booking link and other studio-wide values |
Relationships matter more than field counts. A testimonial linked to a project shows up on that case study automatically, and an Order field on each collection lets editors arrange things without a developer. The general method is in our guide to content modeling.
How do Payload CMS roles work for a small team?
Payload roles are a field on the users collection plus access functions that check it. We use two: admins manage people, leads and site settings, and editors change site content only. That split covers most small marketing teams.
- New users default to editor. Nobody gets admin rights by accident.
- Only admins can change the role field. Field-level access stops editors promoting themselves.
- Editors can read and update only their own user record. Admins see everyone.
- Admin-only areas are hidden from editors' navigation, not just blocked, so the admin stays simple for them.
For larger teams with contributors and approvals, the patterns in CMS roles and permissions extend this with a review step before publishing.
What makes the Payload admin work for editors?
Editors judge a CMS by its admin, so we treat the admin as a product. Ours has sidebar navigation grouped by job, an overview dashboard, drag-and-drop ordering, version history on pages and posts, and the studio's own branding on the login screen.
Drafts and preview do the most work. Blog posts are drafts until published, and only published posts reach the site and the sitemap. Each post and project has a preview link that opens the real page. If your team needs to see changes as they type, add live preview and visual editing on top.
What does deploying Payload on Cloudflare Workers involve?
Deploying Payload on Cloudflare Workers means building Next.js with the OpenNext Cloudflare adapter, storing data in a D1 database and uploads in R2, and working around a few platform limits. It runs well once set up, but it isn't a one-click deploy. The full guide is in hosting Next.js on Cloudflare.
Use the paid Workers plan
The free plan's CPU time per request is too little for the Payload admin, its API and background page rebuilds. Cached pages still load on the free plan, but edits don't reach them.
Build with webpack
We build with next build --webpack, as Payload's official Cloudflare template does, because the adapter couldn't yet resolve Turbopack's server output. Pin Next.js and the adapter together.
Replace sharp
Workers can't run sharp, so uploads are stored as-is in R2 and resized on request through the Cloudflare Images binding, with each size saved back to R2.
Patch password hashing
Workers caps the PBKDF2 iteration count below what Payload uses by default, so sign-up and login fail until Payload is patched to match.
Use REST and the Local API
GraphQL isn't fully supported on Workers yet, so we turned it off.
Cache pages at the edge
Pages are prebuilt and cached, then rebuilt in the background about a minute after an edit, so the admin can stay dynamic while the site stays fast.
What else should a production Payload setup include?
A production setup also needs backups, migrations and a plan for upgrades. We run a nightly job that copies every database table and every upload to a separate R2 bucket, on top of the database's own point-in-time restore. Schema changes go through Payload migrations that run before each deploy.
Illustrative example: applying this to a Series A SaaS site
For example, suppose a SaaS team with two marketers and one part-time developer wants Payload. We'd model pages as a collection with page builder blocks, the blog as a collection with drafts, customers and integrations as collections, and pricing and navigation as globals.
The marketers would be editors and the developer an admin. Preview would be on from day one. Hosting would follow the team: a Node host if they already run one, Workers if they want the edge cache and are comfortable with its limits. This is a planning sketch, not a real client.
Plan for upgrades too. Payload and Next.js move quickly, and on Workers the adapter has to keep up, so updates are a regular task rather than a yearly event. Our guide to Next.js maintenance covers a schedule that works.
