CodeVetter · Repo Unpack · System map
payloadcms/payload
The configuration and core Payload instance form the backend center of the system. Framework adapters expose that backend through HTTP handlers and server-rendered admin entrypoints, while shared UI code owns much of the admin implementation. Persistence is adapter-specific, with separate database, KV, email, and file-storage boundaries. The inspected workspace is a canary monorepo, so versioned source takes precedence over older architectural descriptions.
- The root is a private ESM monorepo at 4.0.0-canary.37; pnpm-workspace.yaml includes packages, tools, the test workspace, and four template workspaces, with pnpm 11.9.0 pinned.
- Generated Next.js app wiring delegates REST verbs to @payloadcms/next/routes, admin pages to RootPage, and server functions plus layout rendering to @payloadcms/next/layouts.
- The REST adapter calls handleEndpoints, whose Fetch Request/Response interface is documented for other backend frameworks; routing selects root, collection, or global endpoint tables.
- Shared admin renderRoot accepts injected context initialization, view adapters, redirect, and notFound functions; its route-key contract explicitly accommodates TanStack Start and Next.js remount differences.
- BasePayload initializes config.db and config.kv independently, then initializes a configured email adapter or falls back to consoleEmailAdapter.
- MongoDB creation uses Mongoose Model.create and session-aware transforms; postgresAdapter imports CRUD, version, transaction, and migration implementations from @payloadcms/drizzle.
- build:core excludes plugin and storage packages plus templates, build:all broadens package builds, and Turbo orders builds through dependency builds while caching dist output.
- Deployment documentation describes Next.js hosting with separately provisioned database, permanent file storage, email, and CDN requirements; the Astro example instead provides separate Payload and website development commands.