Skip to content

[BUG]: varlock-wrangler deploy does not remove secrets that are missing from the schema, contrary to the Cloudflare docs #1212

Open

Description

@schalkneethling

varlock version

varlock 1.22.0, @varlock/cloudflare-integration 1.6.1, wrangler 4.149.0

Steps to reproduce

  1. Create a Worker that has a secret which is not in .env.schema:
    printf '%s' 'spike-extra' | npx wrangler secret put SPIKE_EXTRA_SECRET --name my-scratch-worker
  2. Deploy with Varlock. The .env.schema declares one @sensitive item, TYPESAFE_API_KEY, and does not mention SPIKE_EXTRA_SECRET:
    npx varlock-wrangler deploy --name my-scratch-worker
    It prints Deploying with varlock: 0 vars, 1 secret and succeeds.
  3. List the Worker's secrets:
    npx wrangler secret list --name my-scratch-worker --format json

What is expected?

The Cloudflare integration docs say that SPIKE_EXTRA_SECRET should be gone after step 2 (https://varlock.dev/integrations/cloudflare/):

varlock-wrangler deploy replaces all Cloudflare vars and secrets with the ones defined in your .env.schema. Any vars or secrets set manually via the Cloudflare dashboard or wrangler secret put that aren't in your schema will be removed on the next deploy.

The "Vars or secrets missing after deploy" troubleshooting section says the same: "Manually added dashboard secrets not in your schema are removed".

What is actually happening?

The extra secret survives the deploy. Step 3 prints:

[
  { "name": "SPIKE_EXTRA_SECRET", "type": "secret_text" },
  { "name": "TYPESAFE_API_KEY", "type": "secret_text" },
  { "name": "__VARLOCK_ENV", "type": "secret_text" }
]

This appears to be Wrangler's documented behaviour, not a bug in how varlock-wrangler builds the upload. varlock-wrangler deploy passes secrets with --secrets-file, and wrangler deploy --help (4.149.0) says of that flag:

Applies additively with secrets from previous deployments - omitted secrets will not be deleted.

So the docs promise something the deploy doesn't do for secrets.

I only tested secrets, not vars. The --keep-vars=false that varlock-wrangler adds to a plain deploy suggests the docs are accurate for vars.

System Info

macOS 27.0.1, Node v24.21.0, Apple Silicon
varlock 1.22.0
@varlock/cloudflare-integration 1.6.1
wrangler 4.149.0

Any additional comments?

This matters for anyone who relies on the docs to clean up. For example, if you delete a key from your vault expecting the next deploy to remove it from the Worker, the old secret actually stays live until you run wrangler secret delete.

Either of these would resolve it:

  • Change the docs (both the integration section and the troubleshooting note) to say that secrets are added or updated but never removed, and that removing a secret needs wrangler secret delete.
  • Or make varlock-wrangler deploy delete secrets that are not in the schema, for example by listing them with wrangler secret list --format json and deleting the ones the schema doesn't own, while leaving __VARLOCK_ENV* alone. Deleting secrets is destructive, so it probably belongs behind a flag.

Found while checking the integration for a multi-provider Workers project. Thanks for Varlock; the rest of the integration worked exactly as documented.

Activity

  1. pullfrog commented on Oct 13, 2026

    @pullfrog
    Contributor
  2. theoephraim commented on Oct 13, 2026

    @theoephraim
    Member

    See cloudflare/workers-sdk#15343

    I actually discovered this recently, but did not realize the docs were misleading.

    At the moment I believe it is a limitation of cloudflare and not something we can fix, but I will be pushing them to get a new flag into wrangler/cf so we can opt into "this tool completely manages env vars" behaviour.

    Thanks for the report - will update the docs in the meantime!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions