Reloading Secrets

Goal

Understand why vault updates do not automatically appear in your shell, and learn how to fix it with dse reload and dse up.

Prerequisites

• Getting Started completed (shell plugin installed, at least one secret loaded via .secenv)

The problem

1. Open two terminals

   In Terminal 1, enter your project directory:

   cd ~/my-project
   echo $DATABASE_PASSWORD
   # Output: s3cr3t-db-pass

2. Update the secret in Terminal 2

   echo "new-rotated-password" | dotsecenv secret store DATABASE_PASSWORD

3. Check Terminal 1

   echo $DATABASE_PASSWORD
   # Output: s3cr3t-db-pass   <-- still the old value!

   Caution

   The shell plugin loads secrets when you cd into a directory. It does not poll the vault for changes. Your environment is now stale.

The fix: dse reload

1. Run dse reload in Terminal 1

   dse reload
   # dotsecenv: loaded 1 secret(s) from .secenv: DATABASE_PASSWORD

2. Verify the new value

   echo $DATABASE_PASSWORD
   # Output: new-rotated-password

When to use dse reload

• You stored or rotated a secret in another terminal or on another machine (after git pull)
• You edited the .secenv file (added or removed a variable)
• A secret fetch failed and you want to retry

Bonus: dse up

If you open a terminal directly in a subdirectory (for example, an IDE terminal opening in ~/my-project/src/), the parent .secenv was never traversed. Use dse up to walk up the directory tree and load all ancestor .secenv files:

cd ~/my-project/src
echo $DATABASE_PASSWORD
# Output: (empty)

dse up
# dotsecenv: loaded 1 secret(s) from .secenv: DATABASE_PASSWORD

echo $DATABASE_PASSWORD
# Output: new-rotated-password

Next steps

• Shell Plugins — trust system, tree-scoped loading, nested .secenv files
• Share a Secret — share secrets with teammates