Production checklist

Two things every real deployment must get right that a local project does not: who can edit, and where data lives.

Access controlCopy Anchor Link

Payload does not restrict reads and writes just because a collection has auth: true or drafts enabled. So every collection in @olgax.com/payload-preset explicitly defines its access rules:

The Local API used by the app's own routes bypasses access control by default. The write paths that matter, saving a draft and publishing, check for a signed-in user first and then run with access control enforced, so Payload's rules are the real enforcement and not just a UI check. The /<slug>/edit route also redirects anonymous visitors to /admin/login instead of rendering the editor.

DatabaseCopy Anchor Link

Use Postgres in production. It is an environment change only:

DATABASE_URL=postgres://user:password@host:5432/dbname

Any managed Postgres works, such as Neon, Supabase, Railway or Vercel Postgres.

If you do keep SQLite (file:./payload.db), the database file lives on the server's disk. Put it on a persistent volume, and take backups.

MigrationsCopy Anchor Link

Local development does not need migrations. Payload's dev-mode schema push applies changes automatically, which is fine for disposable data. A real deployment should use migrations:

pnpm migrate:create   # write a new migration from the current schema diff
pnpm migrate          # run any pending migrations
pnpm migrate:status   # list applied and pending migrations

Run pnpm migrate:create after any schema-affecting change, commit the generated file, and run pnpm migrate as part of every deploy. Migrations land in the project's migrations/ folder whichever database adapter is active.

Localized fieldsCopy Anchor Link

Marking an existing field localized: true (as page title and data and section content already are) changes how the column is stored. Accepting the prompt on a populated table drops the old column. Write a migration that moves the existing values first, or add localization from the start on a fresh project.

Secrets and environmentCopy Anchor Link

• Set a strong, unique PAYLOAD_SECRET for every environment. Never reuse your local one.
• Set NEXT_PUBLIC_SITE_URL to your public URL.
• Change the seeded [email protected] password, or delete that user after creating your own.
• Do not commit .env.

Before a real launchCopy Anchor Link

• Configure an email adapter. Payload logs verification and reset emails to the console otherwise. See Payload's email docs.
• Use Postgres, and run pnpm migrate during deploys.
• Decide where uploaded media is stored. See Self-hosting.
• Remember there are no roles yet. Any signed-in user is a full editor, so only create accounts for people you trust.
• Optionally connect Umami.

QuestionsCopy Anchor Link

If something here does not match what you see, tell us on Discord or open a GitHub issue.