On this page
  1. Supported versions
  2. What "available" means
  3. Validate your adoption

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

SurfaceSupported
Node.js20, 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 compositionsChakra UI 3 with Emotion 11, for React DOM
Managed Prisma schema fragmentsPrisma 6.7 through 7
BullMQ queue adapterBullMQ 5.16 through 6
ESLint pluginESLint 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 testing entry 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.

Go

Playstack Pro tag
OriginsPricingBlogNewsletterChangelogStatusRoadmap
ContributorsCommunityIn Use ShowcaseCase StudiesPartnersSponsors
FAQsSupportContact

© 2026 Playstack. All rights reserved.

With OSS
Terms of ServicePrivacy PolicyCookie PolicyImprint

By

Commune Software