Payload CMS

Payload powers the admin panel and the Local API used by the frontend. This page summarizes how this boilerplate uses Payload; for concepts like collections, access, and hooks, see the Payload CMS Docs .

Role in this app

• Collections — Tenants, Users, Pages, Posts, Media, Products, and any custom collections you add. Each defines fields, access control, and optional hooks.
• Admin — The UI at /admin is Payload’s admin. Users log in via Payload auth (separate from frontend customer auth).
• Frontend auth — Customer sign-in and sessions are handled by Better Auth; Payload is used for admin users and for storing/customizing auth-related data as needed.

Critical rules

When extending or writing code that uses Payload’s Local API:

1. Override access — The Local API bypasses access control by default. Whenever you pass a user (e.g. from the frontend or tenant context), set overrideAccess: false so permissions are enforced. Otherwise you risk exposing or mutating data the user shouldn’t see or change.
2. Pass req in hooks — In collection hooks (e.g. afterChange), always pass req into any nested Payload call so the operation runs in the same transaction and context.
3. Avoid hook loops — If a hook updates the same collection (or another that triggers the same hook), use a context flag (e.g. context.skipHooks) and pass it through to avoid infinite loops.

These are documented in the project’s AGENTS.md and in Payload: Security .

Commands

After changing collection or global config:

• pnpm run generate:types — Regenerates payload-types.ts so TypeScript stays in sync with your schema.
• pnpm run generate:importmap — Regenerates the admin import map after adding or changing custom admin components.

Learn more

• Payload CMS Documentation  — Collections, fields, access, hooks, and deployment.
• Payload LLM context  — Long-form reference for tooling and LLMs.