Compatibility and support
The runtimes, frameworks and infrastructure versions Playstack packages target, and how to validate an adoption.
Playstack packages share one release version. The ranges below summarize compatibility targets, not evidence that every version/provider combination has been tested. Check the installed package's peer requirements and adapter-specific qualification notes before choosing a deployment stack.
Supported versions
| Surface | Supported |
|---|---|
| Node.js | 20, 22 and 24; new server projects should start on 22 or newer |
NestJS bindings (nest-*) | Nest 10 and 11 |
React bindings (*-react) | React 18.2 and 19 |
Next.js bindings (*-next) | Next 14.1 through 16; Cache Components need Next 16 |
| Chakra compositions | Chakra UI 3 with Emotion 11, for React DOM |
| Managed Prisma schema fragments | Prisma 6.7 through 7 |
| BullMQ queue adapter | BullMQ 5.16 through 6 |
| ESLint plugin | ESLint 9 and 10 |
Provider SDKs (Stripe, Resend, Cloudflare, push transports and others) keep their own peer ranges, listed on each integration page. A tool's own engine requirement, such as the Node version an ESLint major needs, applies alongside the Playstack range.
What "available" means
- Available means an implementation is present in this documentation snapshot, not that registry publication or production qualification is complete. Check preview access before installing.
- Preview means an initial composition ships with explicit limitations, typically a UI composition or a new adapter.
- Planned means a capability has a name and a direction but no published package yet.
The status page lists every package and adapter with its current label.
Validate your adoption
Playstack packages ship the runtime code, in-memory test doubles and adapter conformance helpers you need to prove a composition in your own application. Before cutover:
- Run the persistence conformance helper from each package's
testingentry point against a disposable copy of your real database, so transaction handles, locking and rollback are exercised where they will run. - Keep the required adapters and registration checks on the same physical transaction as the domain calls, not merely the same transaction label.
- Exercise provider integrations against a sandbox account. Package tests use transport doubles; your deployment's egress, DNS and TLS behavior is yours to verify.
- Never point a mutating conformance suite at production data.
If something in this table does not match what you run, send feedback or ask on the pricing access list; compatibility gaps are prioritized ahead of new features.