---
package: payload
version: "^3.14.0"
tier: core
decision: approved
date: 2026-05-14
deciders: [Danijel Martinek]
adr: null
lastRevalidated: null
is-sub-processor: false
processes-pii: true
filter-results:
  license: MIT
  types: native
  maintenance: active
  boundary-fit: pass
  shadow-check: pass
  eu-residency: self-hostable
  cve-scan: clean
  named-consumer: pass
  socketRisk: clean
verification-commands:
  - npm view payload license
  - npm view payload version
  - pnpm audit --audit-level=moderate
accepted-cves: []
---

## Filter: license

<!-- Result: MIT -->

`npm view payload license` returns `MIT`. MIT is on the allowlist.

## Filter: types

<!-- Result: native -->

Payload CMS is authored in TypeScript and ships its own `.d.ts` declaration files. No separate `@types/payload` package is needed.

## Filter: maintenance

<!-- Result: active -->

Actively maintained by the Payload CMS team. The 3.x line is the current major and receives regular releases. Last release < 18 months, active issue tracker.

## Filter: boundary-fit

<!-- Result: pass -->

Payload CMS is the workspace CMS and repository backend. Feature packages (`@repo/auth`, `@repo/blog`, etc.) use Payload as the data layer via the repository pattern (ADR-002). `core-cms` and `core-shared` use Payload directly. ESLint boundary rules restrict direct Payload queries to repository implementations only — feature packages MUST NOT call `payload.*` outside their repository files.

## Filter: shadow-check

<!-- Result: pass -->

Payload is the sole CMS and ORM-like data layer in the workspace. No competing headless CMS or database abstraction (Strapi, Sanity, Prisma, etc.) is present or proposed.

## Filter: eu-residency

<!-- Result: self-hostable -->

Payload CMS is a fully self-hosted solution. No data is transmitted to Payload-controlled endpoints at runtime. EU residency is inherent; the deployment environment controls data location.

## Filter: cve-scan

<!-- Result: clean -->

`pnpm audit --audit-level=moderate` reports no advisories against `payload` at the time of this trace.

## Filter: named-consumer

<!-- Result: pass -->

All five feature packages (`@repo/auth`, `@repo/blog`, `@repo/media`, `@repo/marketing-pages`, `@repo/navigation`) use Payload for repository access. `@repo/core-cms` configures the Payload instance. `@repo/core-shared` receives Payload config at constructor time. `@repo/core-dsr` uses Payload for GDPR DSR operations (data export, deletion, rectification, processing restriction). Named, non-hypothetical consumers exist today.

## Prompt: replaces

Payload CMS replaces hand-rolled REST API + ORM patterns that would require maintaining a separate data layer, schema migrations, and admin UI from scratch. No parallel CMS is running.

## Prompt: migration-cost-out

Hard. Payload is the data store for all content (articles, users, media, navigation). Migrating out requires replacing every repository implementation across five feature packages, the CMS configuration in `core-cms`, the admin UI, and all database schema definitions. The repository interface boundary (ADR-002) limits the feature-layer surface to repository implementations only, reducing blast radius, but the volume and data-format dependencies make migration substantial.

## Prompt: alternatives-considered

1. **Strapi** — Evaluated but rejected; weaker TypeScript support at the time and less flexible content modeling for mixed structured + rich-text content.
2. **Sanity** — SaaS-first model raises EU residency concerns without a self-hosted plan; Payload's self-hosted model is a better fit for the compliance profile.