Next.js + Payload: One App for Site and CMS

A client recently asked me about consolidating their tech stack. They had a beautiful Next.js marketing site. Separately, they managed blog posts and team bios in a headless CMS. Adding a new team member meant updating their data in two places: the CMS and a static JSON file in the Next.js repo. It was a small friction point, but it highlighted a common issue. Multiple systems mean more places to maintain, more deploys, and more chances for data to get out of sync. This client wasn't alone. Many founders I work with start with a separate frontend and backend, then realize the operational overhead adds up. They want to simplify.

That's where integrating a CMS directly into your Next.js application comes in. Specifically, I’ve been using Payload CMS for this. It lets you run your content management system and your public-facing website from the same Next.js application. This isn't just about convenience. It’s about reducing complexity, speeding up development, and creating a more cohesive developer experience. You manage content, user authentication, and your entire data model within the same project that serves your website. It’s a powerful approach for solo builders and small teams.

Why Combine Them?

The primary benefit is unification. You have one repository, one `node_modules` folder, one build process. This simplifies deployment significantly. Instead of deploying your frontend to Vercel and your headless CMS to a separate server or service, both live together. A single `git push` can update your website content and your entire CMS dashboard.

Consider a typical scenario. You're building a product site. It has marketing pages, a blog, and maybe a small customer portal. With a decoupled setup, your marketing site is Next.js. Your blog posts are in Contentful or Strapi. Your customer data might be in a custom Node.js API. That's three distinct systems, each with its own authentication, data models, and deployment pipeline. Each system requires specific knowledge to maintain.

By bringing Payload into your Next.js app, these concerns merge. Your blog posts, marketing page copy, customer data – it all lives in Payload collections within your Next.js project. Your Next.js pages can then fetch this data directly from the Payload API endpoints, which are served from the same application. This reduces context switching for developers and simplifies how you reason about your data flow.

Another practical advantage is consistency. If you update a data model in Payload, your Next.js application immediately knows about it because they share the same TypeScript types. There's no need to regenerate SDKs or manually sync types between different services. This tight coupling accelerates development and reduces bugs related to data shape mismatches. It’s a holistic approach to full-stack development.

How Payload Integrates with Next.js

Payload is a Node.js-based headless CMS. It can run as a standalone Express app or, more powerfully, be embedded within an existing Node.js application. Next.js applications are Node.js applications. This is key. Payload provides utilities to bootstrap its admin panel and API within your Next.js project. You essentially tell Next.js, "Hey, also run this Payload server here."

The setup usually involves creating a `payload.config.ts` file in your project root. This file defines your collections (like blog posts, pages, users), fields, access control, and other CMS configurations. You then create a file, often `src/payload.ts`, that initializes Payload and exports it. This initialization happens once, usually when your Next.js server starts up. Payload uses its own Express server under the hood, but it's seamlessly mounted onto your Next.js server process.

For your Next.js pages, you can fetch data from Payload in two main ways. For static site generation (SSG) or server-side rendering (SSR), you can import the Payload instance directly into your `getServerSideProps` or `getStaticProps` functions. This allows for direct database queries without network overhead. It's incredibly fast. For client-side data fetching, or if you prefer a traditional API approach, Payload exposes its own REST and GraphQL APIs. You can hit these endpoints from your client-side React components using `fetch` or a library like `react-query`.

The development experience is cohesive. You run `next dev`, and both your Next.js frontend and the Payload admin panel are available, typically on different routes of the same domain (e.g., `localhost:3000` for the site, `localhost:3000/admin` for Payload). This means you can be developing a frontend feature, switch to the admin to add some test content, and see it reflected immediately without restarting servers or managing separate environments.

Real-World Scenarios and Trade-offs

Imagine building an event management platform. You need public event pages (Next.js), an admin dashboard for organizers to create and manage events (Payload), and user authentication for attendees to register (Payload users collection). All of this can live in one Next.js application. Your `[slug].tsx` page fetches event details directly from Payload's database. Organizers log into `/admin` to manage their events. It's a single, unified system.

Another example: a small e-commerce site. Product listings, categories, and inventory can be managed in Payload. User accounts and orders can also be Payload collections. Your Next.js frontend fetches product data for display. When a user places an order, you create a new entry in the 'Orders' collection via Payload's API. Payment processing can integrate with Stripe, sending webhooks back to your Next.js app, which then updates the order status in Payload.

Of course, there are trade-offs. The main one is that your CMS is now tied to your application. If your Next.js application goes down, so does your CMS. This might not be ideal for very large enterprises with separate teams managing content and frontend. But for small businesses and solo founders, this risk is often acceptable in exchange for simplicity.

Another consideration is scaling. While Payload is highly performant, if your site requires extreme global distribution or very specific edge caching strategies that conflict with Payload's server-side operations, you might need to decouple. However, for 90% of web applications, this combined approach scales perfectly well on platforms like Vercel or Netlify (for the Next.js part) and a suitable database provider (like MongoDB Atlas or Supabase for PostgreSQL, as Payload supports both). The key is that Payload's database queries are fast, and your Next.js pages can be statically generated or server-rendered efficiently.

Database and Hosting

Payload stores its data in a database. It supports MongoDB and PostgreSQL. For many projects, MongoDB Atlas offers a generous free tier and easy scalability. PostgreSQL options like Supabase or Neon are also excellent, especially if you prefer relational databases. Your Next.js application connects to this database directly for Payload operations.

Hosting is straightforward. You deploy your Next.js application as usual. If you use Vercel, for example, your `payload.config.ts` will be part of the build. Vercel's serverless functions will handle the Payload API routes and admin panel. This works because Payload's core operations are stateless and can execute within a serverless function's lifespan. You need to ensure your database connection is available from your deployment environment.

For non-serverless deployments (e.g., a traditional Node.js server or Docker container), you simply run your Next.js application as a single process that handles both the frontend serving and the embedded Payload server. This offers even more control over the environment and long-running processes if needed, though for most web apps, serverless is sufficient and more cost-effective.

The critical part is setting up environment variables correctly for your database connection strings and any Payload secrets. Treat these like any other sensitive configuration.

When Not to Combine

This approach isn't for everyone. If you have a massive marketing department that needs a fully separate, enterprise-grade CMS with complex workflows and many non-technical users, a dedicated SaaS CMS might be better. Think Contentful, Sanity, or Strapi Cloud.

If your frontend is built with something other than a Node.js framework, this integration won't work. If you have a highly distributed microservices architecture where the CMS is just one of many independent services, keeping it separate might make more sense.

If you truly need extreme decoupling for scaling different parts of your application independently to millions of users, separate services are often the answer. But for the vast majority of small to medium-sized applications, the combined approach simplifies development without sacrificing performance or scalability.

Practical Steps This Week

If you're already using Next.js and considering a CMS, take some time to explore Payload's documentation on integrating with Next.js. Start a new Next.js project and follow their "Getting Started with Next.js" guide. See how the admin panel comes up within your local development server. Experiment with creating a simple collection, like `Posts`, and fetching data from it into a `pages/blog/[slug].tsx` file. Get a feel for the unified development flow. It can significantly streamline your project architecture.

You can book a 30-minute feasibility call with me to discuss your specific project needs.