Description
Varlock's Cloudflare integration ships an in-worker runtime layer (@varlock/cloudflare-integration/init) that performs console redaction and response leak-detection. It works by reading a __VARLOCK_ENV binding from cloudflare:workers. Today that binding is only produced by varlock-wrangler, which shells out to wrangler. There is currently no public, stable way for a different deploy tool to build that binding.
This request is for a small public API (or a documented stable contract) to construct the __VARLOCK_ENV binding entries, so that non-wrangler deploy tools such as Alchemy, SST, Pulumi, and Terraform can set them as Worker bindings.
Motivation
I deploy Cloudflare Workers with Alchemy rather than wrangler (this is the default on a better-t-stack generated project). varlock run -- <deploy> already gives me fail-fast validation and secret injection with no workaround, because Alchemy reads resolved values from process.env. The one capability I cannot reach is the in-worker runtime layer (console redaction and response leak-detection), because nothing sets __VARLOCK_ENV in the deployed Worker unless I use varlock-wrangler.
The runtime consumer in init.ts is already decoupled from the deploy tool. It only reads __VARLOCK_ENV from cloudflare:workers and does not care how the value got there. Only the producer is coupled to wrangler. Reproducing the producer myself would mean depending on the internal varlock load --format json-full --compact output plus the chunking scheme, which is private and can change without notice.
Proposed Solution
Expose a small public function that returns the binding entries, for example:
import { buildVarlockCloudflareBindings } from '@varlock/cloudflare-integration';
const bindings = await buildVarlockCloudflareBindings();
// => { __VARLOCK_ENV: '...', __VARLOCK_ENV_1: '...', ... }Any IaC tool could then set these as (secret) Worker bindings. This keeps the chunking and serialization logic owned by Varlock while letting non-wrangler tools opt in.
Alternatively, document the binding name(s), the serialization format, and the chunking rules as a stable public contract.
Alternatives
- Use
varlock-wrangler for the deploy. Rejected for now because it would replace Alchemy as the Worker deploy tool, and Alchemy manages more than the Worker (D1, domains, and the static site) from one place.
- Reimplement the producer by calling
varlock load --format json-full --compact and chunking manually. Rejected because it relies on internal output that is not a public contract.
- Skip the in-worker layer entirely and rely only on fail-fast validation plus local-dev redaction. This is my current fallback, but it leaves production without runtime redaction and response leak-detection.
Additional Information
Related better-t-stack integration request: AmanVarshney01/create-better-t-stack#1029 (better-t-stack deploys Cloudflare Workers via Alchemy, so this gap affects that integration too).
Environment: solo developer, monorepo, Cloudflare Workers and D1 deployed via Alchemy, Expo mobile app, Astro marketing site.
Description
Varlock's Cloudflare integration ships an in-worker runtime layer (
@varlock/cloudflare-integration/init) that performs console redaction and response leak-detection. It works by reading a__VARLOCK_ENVbinding fromcloudflare:workers. Today that binding is only produced byvarlock-wrangler, which shells out towrangler. There is currently no public, stable way for a different deploy tool to build that binding.This request is for a small public API (or a documented stable contract) to construct the
__VARLOCK_ENVbinding entries, so that non-wrangler deploy tools such as Alchemy, SST, Pulumi, and Terraform can set them as Worker bindings.Motivation
I deploy Cloudflare Workers with Alchemy rather than wrangler (this is the default on a better-t-stack generated project).
varlock run -- <deploy>already gives me fail-fast validation and secret injection with no workaround, because Alchemy reads resolved values fromprocess.env. The one capability I cannot reach is the in-worker runtime layer (console redaction and response leak-detection), because nothing sets__VARLOCK_ENVin the deployed Worker unless I usevarlock-wrangler.The runtime consumer in
init.tsis already decoupled from the deploy tool. It only reads__VARLOCK_ENVfromcloudflare:workersand does not care how the value got there. Only the producer is coupled to wrangler. Reproducing the producer myself would mean depending on the internalvarlock load --format json-full --compactoutput plus the chunking scheme, which is private and can change without notice.Proposed Solution
Expose a small public function that returns the binding entries, for example:
Any IaC tool could then set these as (secret) Worker bindings. This keeps the chunking and serialization logic owned by Varlock while letting non-wrangler tools opt in.
Alternatively, document the binding name(s), the serialization format, and the chunking rules as a stable public contract.
Alternatives
varlock-wranglerfor the deploy. Rejected for now because it would replace Alchemy as the Worker deploy tool, and Alchemy manages more than the Worker (D1, domains, and the static site) from one place.varlock load --format json-full --compactand chunking manually. Rejected because it relies on internal output that is not a public contract.Additional Information
Related better-t-stack integration request: AmanVarshney01/create-better-t-stack#1029 (better-t-stack deploys Cloudflare Workers via Alchemy, so this gap affects that integration too).
Environment: solo developer, monorepo, Cloudflare Workers and D1 deployed via Alchemy, Expo mobile app, Astro marketing site.