# PRNext 0.1.21: leaner Flight, prepared workers and builds PRNext 0.1.21-alpha is available on npm. This version focuses on work that can be avoided without changing what an application renders. Render hosts can prepare the framework before their first dynamic request, builds retain small verified summaries instead of reparsing unchanged files, and cached primitive results take a compact private path while rich React values keep official Flight decoding. This release also tightens the boundary between the public request, the immediate proxy and local control services. It builds on 0.1.20 without introducing a response cache across users. The application keeps responsibility for authorization, data lifetimes and its deployment procedure. ## Prepare every render host before the first dynamic request Explicit --prewarm prepares each render host, then applies the same framework preparation to replacements and hosts waking from idle. At most two preparations run together within the initial 15-second budget. A small internal RSC and HTML model exercises the official renderer without importing an application route or reading account data. Initial readiness waits for this preparation. Application imports, database connections and request data can still add work to the first real render. A later replacement that cannot complete preparation records a diagnostic and retains lazy loading for normal requests. Lazy startup remains the default, and no failed application request is replayed. Measure startup plus the first dynamic response, rather than treating a ready static file as proof that React is warm. ```sh npx --no-install prnext start --workers 2 --prewarm ``` ## Allocate less around the same Flight response Flight transport envelopes and transfer arrays are reused only within their own response and release buffer references after transfer. Large inline bootstrap scripts are encoded directly into bounded buffers. Later allocation changes also defer structures until needed and take a direct path through ordinary complete HTML fragments. The encoded payload, base64 content and CSP nonce keep their existing meaning. Cancellation, reader credits, defensive copies for externally owned storage and response isolation remain in place. Quoted attributes and ambiguous HTML keep the parser path. These changes reduce transport and envelope work without retaining a private response for another request. ## See Flight size and renderer progress in the inspector Opt-in inspection groups Flight bytes, chunks and outcomes by route pattern and render phase. It distinguishes completed, cancelled, failed and timed-out samples, and reports model-ready and shell-ready milestones where observed. RSC and SSR can observe the same payload, so their byte totals and request counts must not be added together. These durations include application work and asynchronous waits, not isolated encoder or decoder CPU. Missing samples stay missing. Diagnostic data excludes payload bodies, cookies, authorization values and raw query data. Optional GC, heap and event-loop diagnostics provide another view, with no GC observer when disabled. V8 profile defaults and explicit operator overrides remain unchanged. ```sh npx --no-install prnext start . --inspect npx --no-install prnext inspect --json ``` ## Reuse small build facts while keeping discovery checks Repeated builds can reuse bounded, typed Oxc summaries containing the directives and exports needed by later stages. These immutable summaries retain neither source text, an AST nor application closures. Identity and generation checks still decide whether a record belongs to the current input; an unavailable or invalid entry leads back to normal work. Native-dependency discovery reuses scoped proofs when a graph is established as native-free. Unknown effects, custom hooks and changing inputs retain their checks. The framework does not blindly replay an opaque graph snapshot. Reference applications and tools also receive selected dependency updates, including the Next 16.4.4, Better Auth 1.7.15 and Redis client 6.3.1 reference baselines. ## Bound file work and expose build phases Standalone tracing copies and framework runtime copies use bounded concurrency, deterministic alias handling and admission budgets. Source changes during a copy remain detectable. If an operation fails, already started writers settle before the temporary stage is abandoned; the previous published build is preserved. Pages server chunks and source maps are rewritten in memory before their first write. build --timings exposes React build phases to distinguish a slow compiler stage from file work. Its total excludes CLI module startup, and nested phases overlap, so adding every duration would count some work twice. Timing reports stay outside deployment manifests and browser assets. ```sh npx --no-install prnext build --timings ``` ## Keep React in charge of cached values and PPR continuation A cached callback still enters the official React renderer once, including its React.cache context. Eligible primitive results use a compact, versioned private format. Objects, React nodes, functions and temporary references keep the canonical Flight path, with original bytes for ordinary rich results. Strings containing a BOM, ill-formed UTF-16 or values near the rendering limit also retain official Flight handling. Request-private scopes, tags, TTLs and fresh decoded objects are preserved. This is a result codec change, not a new cross-user cache. For native PPR, bounded immutable parsing and prefix information can be reused only after the current artifact bytes and SHA have been verified again. Mutable continuations are cloned per request. Nested or otherwise non-direct continuations still take the established normalization path when required. RSC entries also use a new key namespace. After upgrading, old results are not reused: the first calls refill eligible caches, which belongs in your warmup observations. ## Let abandoned development work leave the queue A development request that expires or is cancelled no longer keeps its queued compilation demand alive. A shared compilation already needed by another caller retains its own lifecycle. This distinction avoids doing work solely for a disconnected request without cancelling useful work for another tab. Development RPC notifications remain authoritative after their first accepted publication. A delayed file snapshot can no longer restore a diagnostic that RPC has already cleared. File-only notifications remain available until RPC is established, preserving the existing fallback without mixing stale generations. In development, successive navigations and Fast Refresh also coordinate their Flight streams. An unfinished response can give way to the next route without restoring an older component tree and losing shared layout state. This change applies to development navigation GETs without replaying mutations; production responses and Server Actions retain strict decoding. When navigationCache.authCookies tracks the session cookies, reauthorization still takes priority: one user’s drafts are not reused for another. A Server Action can also replace the view while an already applied update is being confirmed. Fast Refresh now distinguishes that view change from cancellation of the update. Genuine errors, cancellation and network deadlines remain failures, without resending the Action. This development integration remains tied to the React version qualified with PRNext. It uses an experimental Flight client option without enabling that behavior in production. ## Qualify Node 26 with the same application artifacts Linux CI adds Node 26 checks for runtime and HTTP, Chromium, the SaaS consumer and packaged installations, including hoisted and nested layouts. This browser coverage is Chromium. It does not replace the main Linux, macOS and Windows matrix or select a deployment’s Node runtime. Functional coverage does not provide a throughput figure for Node 26. Compare a runtime change with the same artifacts and dependencies, then check your own application journeys. No numerical Node 26 gain is attributed to this campaign, which runs on Node 22.23.4. ## Read each performance result at its actual scope The controlled comparison from published 0.1.20 source to candidate source 7c15132a runs on Linux x64 and Node 22.23.4. It includes twelve pairs per route and 72 windows in total, with two workers, visible ceilings of two CPUs and 5 GiB, and affinity to those two CPUs. Each window lasts fifteen seconds after two seconds of warmup, with eight SSR connections, two JSON API connections and eight streaming connections. The measurement records 774,665 useful responses completed within the windows, and 775,089 including drain. The 424 drain completions do not contribute to throughput. HTTP, transport and validation error counters are zero. Warmup is separate: 51,123 completions within its windows and 51,552 including its drain. Median paired candidate/baseline throughput ratios are 0.9944 for SSR, 0.9941 for the JSON API and 0.9978 for streaming. The corresponding p95 ratios are 1.0361, 1.0056 and 1.0028. Every reported paired interval includes 1. The predeclared budgets, at most a 10% throughput drop and a 15% p95 increase, are met. These results near the baseline do not demonstrate a general speedup. The baseline JavaScript archive exactly matches published 0.1.20, and the candidate archive matches this source’s Linux qualification. Both native executables were rebuilt separately, however: they are not the exact bytes of the historical public native or the qualified release native. The result compares these source-associated assemblies without isolating JavaScript changes. Kernel and process observations are verified for all 72 samples. Memory remains sampled, namespace-hidden parent limits and runner contention remain outside that verification, and other build or transitive dependencies are not all certified byte for byte. These three synthetic workloads establish neither a global CPU or RAM reduction, production capacity nor an SLA. ## Keep public origin and local control boundaries explicit The saved public-origin and trusted-proxy policy now applies at development, persistent and native multi-application ingress, including HTTP and WebSocket forwarding. PRNext evaluates the real connecting peer before accepting forwarded authority or protocol. A configured canonical origin takes priority; trusting a proxy still does not certify an entire forwarded client-IP chain. Image fallback URLs are assembled from URL components, and their final normalized origin is checked before an internal-fetch exception is granted. Compiler and supervisor RPC authenticate both endpoints and bind fresh nonces to the exact command and response bytes. Messages and deadlines stay bounded. This protocol change makes stopping the old supervisor before upgrading an essential part of the migration. ## Stop the old supervisor before replacing its CLI If you use the persistent supervisor, inspect it and stop it with the still-installed old CLI under the same PRNEXT_PM_HOME before replacing packages. pdown affects the supervisor and all managed applications sharing that home, so plan their maintenance together. A global CLI update alone does not replace every application runtime. Keep application source, lockfile, configuration, build and a compatible database backup for rollback. ```sh npx --no-install prnext pstatus --json npx --no-install prnext pdown npm install @thomas.f/prnext@0.1.21-alpha npx --no-install prnext check --production --json npx --no-install prnext build ``` Keep optional native dependencies enabled and framework and native versions aligned. React, React DOM and react-server-dom-webpack remain aligned at 19.3.1; supported Node ranges are ^22.23.4, ^24.22.1 or >=26.12.1. Rebuild each enabled application with its new runtime before restarting the intended supervisor. The new CLI refuses the incompatible old protocol instead of silently taking over. PRNext remains an alpha with partial Next.js compatibility. A representative application pilot and its own reliability objectives still need qualification. Validate sign-in, account switching, navigation, forms, streaming, dependency failures and rollback with your product. Updating the npm framework does not deploy PRNext Host or any external service, and code rollback does not undo database writes. ## Technical references The seven packages for 0.1.21-alpha are available on npm. The implementation and controlled comparison below explain the changes, their conditions and the limits of the measurements. [PRNext 0.1.21-alpha on npm](https://www.npmjs.com/package/@thomas.f/prnext/v/0.1.21-alpha) [Framework changes and implementation](https://github.com/Lorkydey/PRNext/pull/59) [Proxy, image and local RPC hardening](https://github.com/Lorkydey/PRNext/pull/56) [Navigation, Fast Refresh and upgrade notes](https://github.com/Lorkydey/PRNext/pull/60) [Navigation and Fast Refresh reliability](https://github.com/Lorkydey/PRNext/pull/61) [Published framework source 7c15132a](https://github.com/Lorkydey/PRNext/commit/7c15132ade6da37c8a858873d405b33b4e566874) [Controlled comparison with 0.1.20](https://github.com/Lorkydey/PRNext/actions/runs/42340893273) Published: 2026-11-07 Modified: 2026-11-07 Author: PRNext --- Language: en Canonical: https://prnext.dev/blog/prnext-0-1-21-flight-cache-node26-builds Index: https://prnext.dev/llms.txt