# Next.js boilerplate with Payload blog

> Payload CMS running inside this Next.js app, with the admin panel at /cms. Content lives in the Postgres database you already chose. Blog pages read through the local API, not over HTTP. Drafts autosave, previews are authenticated and SQL migrations are committed.

A full CMS in your own repo and database. No second service, no content API bill.

- **Category:** Content
- **Pricing:** Free and open source (MIT). You host it, so the cost is the Postgres and Vercel functions you already pay for. Payload also sells an Enterprise plan with dedicated support and SSO. It has no public price.
- **Best for:** Teams who want editors in an admin UI but will not put their content in someone else's database. Strong when CMS content joins application data. Also when you need custom fields, hooks or access rules a hosted CMS will not give you. Or when data residency and export matter.
- **Requires:** database
- **Conflicts with:** blog-mdx, blog-sanity
- **Vendor docs:** https://payloadcms.com/docs

## Trade-offs

- You operate it. Migrations, backups, upgrades and the admin bundle's build time are yours. A hosted CMS has none of that, and that is the whole trade.
- It shares your database connection budget. The admin panel and your app draw from the same pool, so on serverless a pooled connection string is not optional.
- Cold starts are real. The admin routes load Payload, the database driver and the editor bundle, so the first hit after idle is slow. It is an internal tool, so this is usually fine. Tell your editors before they report it as a bug.
- Uploads need an object store before you deploy. Local disk works on your laptop and disappears on serverless. The media collection ships pointed at `public/media` and must be repointed.
- Schema changes are code plus a migration. That is a feature in review and a speed bump when an editor asks for one more field.

## Known fixes it ships

- [Payload access control when your app already has auth](https://agenticboilerplate.com/cookbook/blog-payload/access-control-matching-your-auth-battery): Two user tables is the right answer. Map your app's roles onto Payload's rules instead of merging the tables, and never leave an access block undeclared.
- [Payload uploads vanish after a deploy: move media to an object store](https://agenticboilerplate.com/cookbook/blog-payload/media-on-an-object-store): staticDir writes to a filesystem that disappears on serverless. Add a storage adapter, keep the database rows, and migrate the files you already have.
- [Payload migrations on Vercel without a broken deploy](https://agenticboilerplate.com/cookbook/blog-payload/migrations-on-vercel): Vercel runs your build, not your migrations. Run them in the build command, forward-only, and split the schema deploy from the code that needs it.
- [Running Payload inside the same Next.js app](https://agenticboilerplate.com/cookbook/blog-payload/payload-inside-the-same-next-app): The admin panel is a route group, not a second service. Route groups, withPayload, the import map and why your blog pages must not fetch their own API.
- [Letting Payload share your Postgres without wrecking your migrations](https://agenticboilerplate.com/cookbook/blog-payload/sharing-postgres-with-your-app-tables): Two migration tools in one database will fight over table names and drop each other's tables. A separate schema keeps them apart for one config line.

## Generate it

[Build a repo with Payload blog](https://agenticboilerplate.com/build?b=blog-payload)

---

Agentic Boilerplate: A Next.js repo your agent already knows. Free during launch, then $99 once.

- Site map for agents: https://agenticboilerplate.com/llms.txt
- Public API: https://agenticboilerplate.com/openapi.json
- Contact: agenticstudio@gmail.com