[BUG]: varlock-wrangler passes invalid `--keep-vars` CLI flag to wrangler

[wladpaiva]

varlock version

@varlock/cloudflare-integration@1.1.1

Steps to reproduce

1. Run vpx varlock-wrangler versions upload
2. Note the invocation creates ... --keep-vars=false in the command
3. Observe Wrangler outputs:

[ERROR] Unknown arguments: keep-vars, keepVars

What is expected?

The command should run without error -- only supported CLI arguments should be passed to wrangler.

What is actually happening?

varlock-wrangler.ts adds --keep-vars=false to the CLI invocation for wrangler versions upload, but Wrangler CLI does not support this flag. This causes an error:

[ERROR] Unknown arguments: keep-vars, keepVars

And the command fails.

System Info

System: macOS
Node.js: v18+
@varlock/cloudflare-integration@1.1.1
Wrangler version: 4.90.1

Any additional comments?

No response

[theoephraim]

Thanks for the report! We use the regular deploy command so didn’t catch this. Will get it fixed shortly.

[wladpaiva]

thanks @theoephraim .

I patched this problem but I got to another problem when running varlock-wrangler versions upload on wrangler@4.9.1.

Wrangler rejects Varlock’s generated --secrets-file.

Varlock was writing the secrets temp file as JSON:

{"BETTER_AUTH_SECRET":"...","TURSO_AUTH_TOKEN":"..."}

But Wrangler expects --secrets-file to be dotenv-style KEY=VALUE content, like:

BETTER_AUTH_SECRET="..."
TURSO_AUTH_TOKEN="..."

This is my patch but after seeing your pr I'm pretty sure I'm breaking something else

diff --git a/dist/varlock-wrangler.js b/dist/varlock-wrangler.js
index 1e58d423aa5c00abb303035e7e18623bb6fc362d..525fc8e19fe4f04a6b48a6d5f697c3b768b25374 100644
--- a/dist/varlock-wrangler.js
+++ b/dist/varlock-wrangler.js
@@ -211,6 +211,6 @@ async function handleDeploy(args) {
   addVarlockEnvToRecord(secretsObj, loaded.json);
   const tmp = createServingTempFile("varlock-secrets");
-  const content = JSON.stringify(secretsObj);
+  const content = Object.entries(secretsObj).map(([key, value]) => formatEnvLine(key, value)).join("\n");
   debug("deploy: starting FIFO serve");
   const handle = tmp.startServing(() => content);
   process.on("SIGINT", () => {
@@ -232,7 +232,7 @@ async function handleDeploy(args) {
   let exitCode = process.exitCode ?? 0;
   try {
     debug("deploy: spawning wrangler");
-    exitCode = await spawnWrangler([...args, ...varFlags, "--secrets-file", tmp.filePath, "--keep-vars=false"]);
+    exitCode = await spawnWrangler([...args, ...varFlags, "--secrets-file", tmp.filePath]);
     debug("deploy: wrangler exited with code", exitCode);
   } finally {
     debug("deploy: cleaning up");

[theoephraim]

Unless they changed it and forgot to update the docs, then json is definitely allowed. What was the error you were seeing?

[wladpaiva]

Weird, I got a message saying that it accepts both file but it failed to accepts the one generated. But now I tried it again and it did not fail

¯_(ツ)_/¯

I guess that's it then.. Removing the keep-vars is the only thing needed

[garron]

I had a similar intermittent/non-reproducible issue passing secrets. In case it helps, here was what my LLM drafted for me as a bug report after troubleshooting, although I haven't done an investigation myself:

varlock-wrangler deploy intermittently produces invalid --secrets-file input when served via FIFO

Summary

We hit a production deploy failure where Wrangler reported:

✘ [ERROR] The contents of "/tmp/.../varlock-secrets-..." is not valid.

The --secrets-file path was created by @varlock/cloudflare-integration's varlock-wrangler, which serves secrets to Wrangler through a named pipe (FIFO).

After investigation, we do not think our generated secrets object is malformed JSON. The stronger current hypothesis is that Wrangler is sometimes reading incomplete / empty / otherwise corrupted bytes from the FIFO-backed --secrets-file path.

Versions

Observed in:

• @varlock/cloudflare-integration 1.1.1
• wrangler 4.90.0 / 4.90.1
• Bun workspace / Linux CI

Observed behavior

Production deploy logs showed Wrangler printing:

✘ [ERROR] The contents of "/tmp/.../varlock-secrets-..." is not valid.

Wrangler's own source says this error is raised when the --secrets-file contents are not valid JSON / dotenv input:

throw new UserError(`The contents of "${input}" is not valid.`)

and for JSON input it additionally expects a JSON object whose values are all strings.

Why we think the payload itself is probably valid

We added instrumentation around our deploy path and inspected the generated secrets payload before Wrangler reads it.

1. varlock-wrangler constructs JSON from a plain object of string values

In dist/varlock-wrangler.js, deploy does this:

• resolve config via varlock load --format json-full --compact
• build secretsObj
• coerce every secret value to a string
• JSON.stringify(secretsObj)
• serve that JSON through a FIFO path passed to Wrangler via --secrets-file

So the intended payload shape is always:

• a JSON object
• all values strings

2. We captured the payload shape for the failing app

For our Worker, the generated secrets payload was small and simple. The top-level keys were only:

• JWT_PRIVATE_KEY
• __VARLOCK_ENV

In local repros, the payload was roughly ~1.3 KB and did not require chunking.

3. The same content works when passed to Wrangler outside the FIFO path

We tested Wrangler directly with:

• a regular JSON secrets file
• multiline secrets
• realistic PEM content
• deploy --dry-run

Wrangler accepted it.

We also tested varlock-wrangler locally against the same app/workspace and could not reproduce the invalid-content error consistently.

Additional evidence

We originally suspected malformed repo-specific content, but ruled out several likely causes:

• not caused by __VARLOCK_ENV_* chunking in our app payload (payload was too small to chunk)
• not caused by multiline PEM content alone
• not caused by unresolved literal infisical() values alone
• not caused by generic Wrangler incompatibility with --secrets-file

That leaves the FIFO transport path as the strongest remaining suspect.

Likely failure mode

varlock-wrangler currently uses a named pipe server for deploy secrets:

• mkfifo
• background Node process repeatedly writeFileSync()s the FIFO contents
• Wrangler reads the FIFO path via --secrets-file

The most plausible remaining explanation is that, in some environments / timing windows, Wrangler reads:

• an empty payload
• a partial payload
• or otherwise invalid bytes

from the FIFO-backed path.

Suggested fixes

Best upstream fix

For one-shot deploys, avoid FIFO serving entirely.

Instead:

1. write the secrets JSON to a secure temporary file with 0600 permissions
2. pass that normal file path to Wrangler via --secrets-file
3. delete the temp file after Wrangler exits

This is much simpler than a FIFO server and should avoid timing/read issues.

[theoephraim]

@garron - thanks for that! The FIFO helps keep things out of plaintext. But definitely needs to be reliable. Will dig in a bit and see what we can do.

How often are you seeing issues like that?