Repository navigation
Next.js: freeze the env into the build only when asked or where it's needed - #1232
Conversation
…t on real payloads in framework tests
…mplify; Docker docs
github-actions
Bot
added
maintainer
core:website
core:varlock
integration:nextjs
labels
|
The changes in this PR will be included in the next version bump.
|
📦 Bundle size
dist/ only; native binaries are versioned separately and not counted here. |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
varlock-website | e8a8174 | Commit Preview URL Branch Preview URL |
Oct 15 2026, 06:41 AM |
varlock
@varlock/nextjs-integration
@varlock/native-helper-darwin
@varlock/native-helper-linux-arm64
@varlock/native-helper-linux-x64
@varlock/native-helper-win32-x64
commit: |
…jects _-prefixed keys)
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
Important
Required boot-only keys still fail during the build, and two production startup paths can resolve fresh values before switching to the frozen env. These need addressing before merge.
Reviewed changes Reviewed the build-time freeze policy, runtime initialization, production boot paths, and associated tests and documentation.
- Freeze policy: Adds
freezeIntoBundle, platform detection, explicit standalone choices, encryption requirements, and shared webpack/Turbopack preludes. - Production boot: Records frozen payloads in Next config and loads them before config evaluation, while non-frozen servers require runtime resolution.
- Boot values: Adds deferred required validation and the
varlock/frozen-env-bootbundle, plus frozen conflict warnings and edge decrypt handling. - Coverage: Updates framework/deployment tests and hosting docs; the integration build and 59 targeted unit tests passed. An actual Next 15 webpack build reproduced the required boot-key failure below.
gpt-6.1-sol ｜ 𝕏
…rvers boot frozen; check the boot source against distDir
There was a problem hiding this comment.
Important
No new issues found in these commits. The three unresolved findings from the previous review remain unchanged, so this is not an approval.
Reviewed changes Reviewed the deployment-test fix and encryption-guide updates since 25d4377.
- Updated deployment setup: Set the plaintext opt-out through Vercel's project-env API, generalized the existing key helpers, and removed per-deployment build-env flags.
- Clarified encryption setup: Distinguished Next.js frozen builds from Vite injection, documented Vercel project variables, and linked Docker build-secret guidance.
Real Vercel deployments were not rerun in this review.
gpt-6.1-sol ｜ 𝕏
There was a problem hiding this comment.
Important
Production build workers can now boot from a previous frozen build, causing valid rebuilds to fail. The expanded startup detector needs to exclude build execution.
Reviewed changes Reviewed the startup and build-resolution fixes in 62d31b9 since the previous review at e8a8174.
- Preserved build resolution: Kept the build's existing graph during frozen-runtime execution and added an unset required boot key to the standalone framework fixture.
- Expanded frozen startup: Included production custom servers in manifest-based initialization before Next config evaluation.
- Checked build sources: Recorded the boot manifest and rejected frozen custom-directory startup, stale output mismatches, and builds contaminated by earlier frozen output.
- Verified focused paths: Built the integration and dependencies, passed 27 focused tests, and exercised the compiled loader with custom-server and build-worker environments. Full framework builds and remote deployments were not rerun.
gpt-6.1-sol ｜ 𝕏
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes Reviewed fc76c20 since the prior review at 62d31b9.
- Excluded build workers: Added inherited-build checks before frozen server detection, preventing workers from loading a previous build's frozen output.
- Added regression coverage: Tested current-graph preservation with old frozen output present and confirmed production custom servers still boot frozen without invoking the CLI.
The integration and its workspace dependencies built successfully, and all 30 focused tests passed. Full Next.js framework builds and remote deployments were not rerun.
gpt-6.1-sol ｜ 𝕏
The Next.js integration baked the fully resolved env (secrets included) into every production build, regardless of host. A standalone server with no varlock CLI then silently booted from build-time values and ignored the runtime env. The docs already said baking only happened on Vercel/OpenNext.
This is the Next.js half of the freeze plan: one decision, made at build, never at boot.
@varlock/nextjs-integration(major)freezeIntoBundleoption:'auto'(default) freezes on Vercel, Netlify, Cloudflare Workers Builds, AWS Amplify and OpenNext builds;truealways;falsenever. Non-frozen builds bake nothing.output: 'standalone'with'auto'on an undetected host fails the build untiltrueorfalseis set, so Docker users hit this in CI rather than at deploy._VARLOCK_ENV_KEY, opt out with_VARLOCK_ALLOW_PLAINTEXT_FROZEN_ENV=1)__VARLOCK_ENV)@dynamic=bootrequired-server-files.json), so the server process boots from it beforenext.configruns. This applies to the standalone server,next start, and custom servers, never to a build or its workers. The config plugin then checks that the boot came from the build being served: a frozen build in a customdistDirundernext start, or a stale frozen.next, fails at boot.next builditself, prerendering keeps the build's own resolution, so required@dynamic=bootkeys with no build-time value don't fail the build.writeResolvedEnvFile.varlock(minor)varlock load --defer-boot-required: the freeze-time tolerance for required boot items, used bynext build.varlock/frozen-env-bootbundle: applies@dynamic=bootvalues for a frozen env baked into a bundle. It is kept out of the init bundles andvarlock/envbecause it carries the data types (~70KB).node:cryptoin data types is now lazy so the bundle loads on edge.initVarlockEnv:__VARLOCK_ENVto its process-start value on re-initinstrumentation.ts)process.getBuiltinModule, so decrypting there now falls back correctly.Testing
next start, standalone with CLI, standalone without CLI} × {not frozen, frozen}, including a@dynamic=bootkey,varlock runon top of a frozen build, and the option variants.encrypted env blobreplaced with not-frozen / frozen-on-Vercel / missing-key scenarios. The old assertion only checked for thevarlock:v1:prefix, which the runtime code itself contains. The standalone scenarios now cover the build guard, the boot failure, and a frozen boot with a@dynamic=bootoverride._VARLOCK_ALLOW_PLAINTEXT_FROZEN_ENVas project env through the API, like_VARLOCK_ENV_KEY: the Vercel CLI rejects env keys that begin with_.