Overview

What knext is

knext is the scale-to-zero Next.js adapter for Knative/Kubernetes — a Next.js-specific deployment framework, architecturally closer to OpenNext than to a PaaS. It runs your Next.js app on the official Next.js Deployment Adapter API with true scale-to-zero: idle services drop to zero replicas and wake on the first request.

It is not a general-purpose PaaS, and not "Coolify for Kubernetes." The differentiator is Knative + scale-to-zero — and, longer term, what that scale-to-zero substrate makes possible: Self-Contained Systems.

Philosophy: Self-Contained Systems

knext exists to make one architectural style cheap and natural to run on your own infrastructure: the Self-Contained System (SCS).

A Self-Contained System is an autonomous web application that owns its entire vertical slice — its UI, its business logic, and its own data store — and integrates with its peers as loosely as possible. The defining constraints:

• It owns its data. Each system has its own database. No system reads another system's database directly. There is no shared schema and no shared data layer.
• It includes its UI. An SCS is a web application, not a headless backend service. This is the key difference from microservices, where the UI lives elsewhere and integration happens server-side behind an API gateway.
• Integration is asynchronous and in the browser. Systems compose primarily through the browser (links and UI composition) and through asynchronous domain events — never through synchronous, request-time calls into each other's internals or databases.
• It deploys, scales, and fails independently. Each system is owned by one team and has its own release cadence; one system being down or redeployed does not take the others with it.

The payoff is autonomy without a distributed monolith: teams move independently, a failure is contained to one system, and the architecture stays legible because each system is small and whole. The classic cost of the style is operational — many small applications to deploy and, naively, keep running.

Why scale-to-zero Next.js on Knative is the natural substrate

That operational cost is exactly what knext removes. The mapping is one-to-one:

One Self-Contained System ≙ one Next.js app ≙ one scale-to-zero Knative Service ("zone").

Each system becomes a knext zone — its own Next.js application that knext deploys as its own Knative Service. Because every zone scales independently to zero, a product made of N systems where most are idle at any moment costs almost nothing to keep available: you pay only for the systems actually receiving traffic, and an idle system is genuinely 0 replicas, not a warm pod. This is what makes "many small autonomous applications" economically viable on your own Kubernetes — not only on a managed PaaS.

The architecture's hard rules map cleanly onto the platform:

• Data sovereignty → each zone gets its own PostgreSQL (provisioned via CloudNativePG) and reads it via a DATABASE_URL from a Kubernetes Secret. A zone never connects to another zone's primary or replica.
• Asynchronous integration → cross-zone state flows only via Kafka domain events (each zone keeps its own copy) and via the browser.
• Browser-side composition → Next.js Multi-Zones stitches the independent zone apps under a single domain, so the user sees one product while each zone ships and scales on its own.
• Independent lifecycle → per-zone build, deploy, rollback, and scale-to-zero are first-class.

In short: SCS is the "why," and scale-to-zero Knative is the "how." Autonomy, independent deployability, and pay-per-use — per self-contained system.

The pillars

• Honest claims, measured in the open. The default build (next build) uses knext's adapter on the official Next.js Deployment Adapter API (@getknext/core/adapter) — the lane the official suite runs against. A selectable vinext build (an open-source Vite-based Next.js implementation, compiled into a single executable) is also available, and knext never blurs which claim covers which path. See The adapter and the compiled build.
• Official-suite compatibility, credential in progress. The official vercel/next.js deploy-mode e2e suite runs against knext several times a day; the 14-run credential is in progress. See the compatibility credential.
• True scale-to-zero. Knative's autoscaler + activator take idle services to 0 replicas and wake them on the first request. See Scale-to-zero & cold starts.
• A compiled executable by default. The standalone server is minified and precompiled to bytecode at build time, then baked together with the Bun runtime into one binary that runs inside the standalone folder. The optional vinext build's whole-app executable measured 61 ms process boot and 1103 req/s against the Node standalone's 884 ms / 630 req/s — local numbers from a warm binary, not a cluster cold start (boot is one component of the Knative cold-start budget, which the platform's scheduling dominates — see Scale-to-zero & cold starts). See Bun & the compiled executable and Bytecode caching.
• Node stays available. Set runtime: 'node' and the same standalone server.js runs under Node with a baked V8 compile cache, exercised against the official suite. See Bun & the compiled executable.
• The operator is the source of truth. A Go operator reconciles a NextApp custom resource into a Knative Service, reports honest Ready/Degraded conditions, and rejects non-digest-pinned (:latest) images. See Operator & the NextApp CRD.
• Bring-your-own database. knext is engine-agnostic: bind an existing Postgres by supplying a DATABASE_URL from a Kubernetes Secret — knext provisions nothing. The optional @getknext/db layer wraps drizzle-orm over that DSN with a typed schema, one-shot writer-only migrations (knext db migrate), and explicit read/write clients (getDb() / getDbRO()). See Databases and the Data SDK.
• Signed, scanned supply chain. Every published image is Trivy-gated before push, carries an SBOM attestation and SLSA provenance, and is cosign-signed on the pushed digest. See Security.
• Multi-cloud object storage. Assets go to gcs, s3, minio, or azure. See Multi-cloud deploy.

This site is built to run on knext

This documentation site is itself a Next.js App-Router app (Fumadocs + MDX). It is built to deploy on knext: it builds with the selectable vinext build (build: 'vinext') and deploys as a scale-to-zero Knative Service. Its dogfood config (knext.config.ts) and deploy runbook (DEPLOY.md) live in the knext repository, under apps/docs.

License

knext is licensed under Apache-2.0.