🚀Feature request: Allow easy overriding of secrets-store in .dev.vars

[medz]

Describe the solution

In the local workers development process, when a worker depends on other workers, and the dependent worker depends on secrets-store secret, this will cause great trouble to the local development process.

When not depending on other workers, we can create an env variable and determine whether it is a string or an Object with a get() method when using it, for example:

/// Bindings.ts
readonly DATABASE_URL: string | SecretsStoreSecret;

/// Using
const databaseUrl = typeof env.DATABASE_URL === "string" ? env.DATABASE_URL : await env.DATABASE_URL.get();

But this is not a panacea. When one of my workers needs to depend on another worker, and the other worker depends on SecretsStoreSecret, problems arise. Even if I declare { "binding": "API", "service": "api-core", "environment": "dev" },, it doesn't work at all. Always appears:

Binding Resource Mode
env.DATABASE_URL Secrets Store Secret loca

And wrangler secrets-store secret is very inconvenient, it needs to be configured once for each worker. The essence of secrets-store is to share secrets between workers.

**Just like Hyperdrive, we can use special variables to override bindings. This can be very useful during development.

Especially when we need to make changes to multiple workers at the same time.**

[penalosa]

Could you expand on your proposed .dev.vars solution? We currently support wrangler secrets-store secret, which allows you to change secrets on a per-worker basis (as .dev.vars would, because that's also per-worker). You can use the --persist argument to Wrangler to make state shared across workers (by providing the same path)—I wonder if that would address the issue?

[medz]

@penalosa Just like when developing hyperdrive locally, you can directly set the local database connection string through the WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_* prefix.

I think secrets-store is also the best, because I am very distressed now. I have three related workers, and I use secrets-store to facilitate the management of some keys.

My compatible code in a single worker is as follows:

type ENV = { xxxxx_KEY: string | {get: () => Promise<string>} }
const key = typeof env.xxxxx_KEY === "string" ? env.xxxxx_KEY : await env.xxxxx_KEY.get();

This is very convenient for local development, but when encountering multiple collaborations, for example:

wrangler dev --cwd /workers/a -c wrangler.jsonc -c ../b/wrangler.jsonc -c ../c/wrangler.jsonc

Need to start a worker, but the configuration of a worker in wrangler.jsonc:

"services": [
  { "binding": "A", "service": "a-worker" },
  { "binding": "B", "service": "b-worker" },
]

Since a and b depend on different secrets-stores, the previous compatible code is no longer available, and child workers are forced to enable local secrets-store binding.

It would be much simpler if it was allowed to override in .dev.vars:
.dev.vars:

SECRETS_STORE_SECTET_xxxxx_KEY=xxx

This allows the bound secrets-store to be directly overwritten during local development, and the local one will be used when the .dev.vars of the dependent worker also has the corresponding configuration.

[NOTE]
The above behavior logic is consistent with the logic of hyperdrive's local development overwriting link string, which is very beneficial for local development.

Now secrets-store uses the wrangler secrets-store secret command to manage the secrets-store for local development, which is very inconvenient and often forgotten. But it is more convenient to manage the keys of the cloudflare platform.

[medz]

Now I have configured more than a dozen different secrets-stores in my account, and they are bound to one or more by different workers. But some workers depend on other workers, and they together form a business logic or workflow. This causes a lot of trouble for using secrets-store locally and starting local development with multiple -c parameters. I can judge by multiple types when developing a single worker without dependencies. Once it comes to worker development that depends on other workers, I must use the wrangler secrets-store secret command to configure keys for multiple dependent workers. Moreover, workers have many repeated dependencies, and configuring secrets-store is much more troublesome than directly writing .dev.vars files, and it is easy to forget. Once a key needs to be updated during development, I need to find all the workers used for local development to configure the local secrets-store command, which is very troublesome.

So I hope to be able to configure the secrets-store for local development directly in .dev.vars, because this will become very convenient for developers during the development process.

[alexkli]

I ran into the same challenge that setting up local secret store for local development is unnecessarily difficult compared to the .env / .dev.vars support for worker secrets/variables.

I scripted a workaround:

1. store secrets like in .secrets file (named it differently as to not conflict with a potential .env / .dev.vars)
2. load-secret-store.sh script that reads .secrets and puts all the secrets into a clean (empty) local secret store using wrangler secrets-store secret create
3. plug this together in via npm run scripts so I just run npm run dev to start local setup

@ Cloudflare team: It would be great if wrangler dev would support something like this out of the box. Eg. automatically create local secret store from some .secrets file. Would probably require including the store ids inside the file, maybe using [<store-id>] sections similar to the wrangler.toml format.

.secrets

Make sure to .gitignore this!

KEY="top-secret"
ANOTHER="super-secret"

load-secret-store.sh

Note this starts with a clean aka empty local secret store by removing all local stores using a simple rm. The wrangler secrets-store currently (version 4.31.0) does not provide a command to delete a store locally.

#!/bin/bash

# Update secrets in local Cloudflare Secret Store

set -e

SECRET_STORE_ID="$1"
FILE="$2"

if [ -z "$SECRET_STORE_ID" ] || [ -z "$FILE" ]; then
  echo "Usage: load-secret-store.sh <secret-store-id> <secrets-file>"
  echo
  echo "Load secrets from <secrets-file> into a local Cloudflare wrangler secret store."
  echo
  echo "<secret-store-id>   Cloudflare secret store ID (same as in production)"
  echo
  echo "<secrets-file>      Properties file with secrets in the following format:"
  echo
  echo "                      # comment"
  echo "                      ONE=\"top-secret\""
  echo "                      TWO=\"super-secret\""
  exit 1
fi

# Clean local secret store
rm -rf .wrangler/state/v3/secrets-store

while IFS='=' read -r key value; do
  # Skip empty lines and comments
  if [[ -z "$key" || "$key" =~ ^# ]]; then
      continue
  fi

  # Trim whitespace
  key=$(echo "$key" | xargs)
  value=$(echo "$value" | xargs)

  # 'secret create' does create OR update
  echo "$value" | WRANGLER_LOG=error npx wrangler secrets-store secret create $SECRET_STORE_ID --scopes workers --name "$key" > /dev/null

done < "$FILE"

package.json

I am using it with these npm run scripts in my package.json:

{
  "scripts": {
    "predev": "./load-secret-store.sh {SECRET_STORE_ID} .secrets",
    "dev": "wrangler dev"
  },
  "devDependencies": {
    "wrangler": "^4.31.0"
  }
}

Local dev server is then started with npm run dev.

[maxprilutskiy]

Tried using remote secrets store and local .dev.vars - and it turned out - when running it locally, the secrets store [local] binding overrides the .dev.vars variable.

What's the best practice here?