feat: encrypt injected env blob for secure serverless deployments#656
Open
theoephraim wants to merge 8 commits into
Open
feat: encrypt injected env blob for secure serverless deployments#656theoephraim wants to merge 8 commits into
theoephraim wants to merge 8 commits into
Conversation
Collaborator
|
The changes in this PR will be included in the next version bump.
|
varlock
@varlock/cloudflare-integration
@varlock/expo-integration
@varlock/nextjs-integration
@varlock/vite-integration
commit: |
d467143 to
93ac514
Compare
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
varlock-website | 14bbc4d | Commit Preview URL Branch Preview URL |
Jun 01 2026, 09:38 PM |
When _VARLOCK_ENV_KEY (64-char hex) is set at build time, the resolved env blob injected into build output is encrypted with AES-256-GCM. At runtime, the init bundles detect the varlock:v1: prefix and decrypt using the same key from the runtime environment. This lets Vercel users set a single env var and have all other config travel encrypted inside the deployment artifact. - New crypto module with sync (node:crypto) and async (Web Crypto) paths - All integration injection points (Next.js, Vite) encrypt when key is present - _VARLOCK_ENV_KEY auto-excluded from injected blob and type generation - varlock generate-key CLI command with --plain flag for piping - Docs for Next.js and Vite integrations - Framework tests for encrypted blob flow
93ac514 to
5978976
Compare
The test was looking for `.next/server/**/*runtime*.js` which doesn't match webpack output files. Changed to `.next/server/**/*.js` and removed the prerendered HTML assertion since the page is dynamic.
philmillman
approved these changes
Jun 1, 2026
Member
philmillman
left a comment
There was a problem hiding this comment.
added a few nits. One thing we may want to consider for the future is whether we allow an arbitrary key name and then do the logic based on a type instead? Also does it make sense to allow them to generate/BYOK?
tsup/esbuild strips the node: prefix from imports, so varlock's built dist uses `import crypto from 'crypto'` instead of 'node:crypto'. Vite SSR only auto-externalizes node:-prefixed imports, so it tries to bundle bare 'crypto' and fails with "Dynamic require not supported". Fix: explicitly add 'crypto' to ssr.external in the Vite plugin config.
esbuild strips the node: prefix from imports, so varlock's built dist uses bare 'crypto' which Vite SSR doesn't auto-externalize. Add it to ssr.external in the Vite plugin config.
esbuild strips the node: prefix from imports, so varlock's built dist uses bare 'crypto' which Vite SSR doesn't auto-externalize. Add it to ssr.external in the Vite plugin, but skip when CF Vite plugin is present since Workers handle node builtins via nodejs_compat.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
- Use dynamic encryption keys in framework tests instead of hardcoded - Improve docs wording for encrypted env blob notes
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Summary
Adds support for encrypting the resolved env blob that varlock injects into server-side build output. This protects secrets from leaking via sourcemaps or build artifact inspection on serverless platforms (Vercel, Netlify, Cloudflare Workers, etc.).
Encryption across all integrations
When
_VARLOCK_ENV_KEYis set (or@encryptInjectedEnvdecorator is enabled), the env blob is encrypted with AES-256-GCM before injection. At runtime, server-only init code decrypts it beforeinitVarlockEnv()runs.globalThis.__varlockEncryptedEnv, decrypted in virtual init moduleprocess.env.__VARLOCK_ENV, decrypted by init-server/init-edge bundlesprocess.env.__VARLOCK_ENVin-place, sets parsed object on globalThisArchitecture
env.tsentirely — nonode:cryptodependency in client-bundleable codeglobalThis.__varlockEncryptedEnvseparates encrypted blobs from parsed objects on__varlockLoadedEnvcrypto.tsuses top-levelimportinstead of brokenrequirein ESM outputNew root decorators
@encryptInjectedEnv— declares encryption intent, supportsforEnv(). Auto-generates key for dev servers and Cloudflare deploys, errors on production builds without key@disableProcessEnvInjection— prevents injecting individual vars intoprocess.env, forcing ENV proxy usage. Combined with encryption = zero plaintext secrets inprocess.envCLI changes
varlock generate-key— fixed for ESM buildsvarlock run --inject <all|vars|blob>— controls what gets injected into child process env (replaces deprecated--no-inject-graph)Docs
Test plan
varlock generate-keyworks@encryptInjectedEnvproduces encrypted output_VARLOCK_ENV_KEYproduces encrypted runtime filesvarlock-wrangler deployauto-generates key@disableProcessEnvInjectionprevents individual var injectionvarlock run --inject blobonly injects blob