The Socket supply-chain filter (ADR-023) was added after the initial library-trace backfill, leaving the 36 traces dated 2026-05-14 without the socketRisk filter-results field the trace schema now expects. Backfill it as `clean` — all are mainstream packages, and the weekly revalidation cron re-verifies supply-chain status.
89 lines
3.6 KiB
Markdown
89 lines
3.6 KiB
Markdown
---
|
|
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.
|