Stability tiers

Not every part of knext carries the same promise. This page states, plainly, which tier a feature is in and what that tier commits to, so you can decide what to build on without guessing.

Stable

A feature is Stable only when a scheduled, red-on-fail check covers it — not because it has "been around a while." Stable features follow the full semver policy: a patch or minor release never breaks them, and a breaking change requires a major version.

• The four default-target runtime x builder combinations: Node/Bun runtime, each with the Turbopack or Webpack builder, on the standalone build target (see How your app is built and Compatibility matrix). Their official Next.js compatibility credential is still in progress — see the compatibility credential for its current status.
• The knext.config.ts schema and the public TypeScript types (@getknext/core, @getknext/lib, @getknext/db).
• The core CLI verbs — create, build, deploy, status, doctor — including their exit codes.
• The NextApp custom resource at v1alpha1 (additive-only — see Versioning).
• Image optimization.
• Graceful shutdown (SIGTERM drain).
• The in-process request body cap on the standalone build target.
• The default NetworkPolicy — enforced only where your cluster's network plugin (CNI) supports NetworkPolicy (Calico, Cilium, and similar); on a non-enforcing CNI (flannel, which OKE and OrbStack run by default) the policy is written but enforces nothing. knext doctor and the NetworkPolicyEnforced status condition report which case you're in — see Security.

Beta

Beta features are shipped and usable, but may still change with notice — typically called out in release notes rather than gated behind a major version. Treat them as ready to build on, with more room for change than a Stable feature.

• knext init-ci
• knext db-bind
• ISR/Redis caching and authenticated cache invalidation
• Object storage on gcs, s3, and minio
• Object storage on azure
• Metrics and observability wiring
• The 0.4.x → 1.0 upgrade path
• The optional scale-to-zero Postgres, built on Neon's open-source storage and compute. See Scale-to-zero database.
• The optional vinext build target (build: 'vinext' in knext.config.ts, --builder vinext on knext create), on both runtimes — the compiled Bun single executable (runtime: 'bun', the default for this target) and the Node server with a baked V8 compile cache (runtime: 'node') — see The vinext pipeline.

ISR/Redis caching and object storage move to Stable once a scheduled, red-on-fail check covers them end-to-end on a real cluster against the default build target — the same bar every other Stable entry above already meets. That check does not exist yet.

The vinext build target stays Beta in every release; it is not on the path to Stable. It is exercised by a scheduled compatibility check that publishes a measured pass/fail count rather than gating on an unbroken green streak; see the compatibility matrix for the current numbers and conditions on each runtime. The four default-target cells above are being credentialed against the 14-consecutive-run bar; the matrix shows their current status.

Experimental

Experimental features are outside the v1.0 contract entirely — they may change in any minor release, with no deprecation window. Each one carries a visible marker where you meet it (in its types, in --help output, or in the relevant reference page) so the carve-out is never a surprise.

• selfContained (knext.config.ts) / knext build --self-contained — see Self-contained mode.
• The directly-runnable preview and loadtest CLI entries — see the CLI reference.

See also the public API reference for the full experimental-surfaces policy over the TypeScript surface.