Skip to content
1Claw Academy
Curriculum/Foundations2 minBeginner · Lesson 8 of 13

Bring your existing .env

Import the .env files you already have, then export them back on demand so your tooling never changes.

Nobody starts from an empty vault. You start with a handful of .env files scattered across projects, which is the exact problem worth solving, so the local vault imports them directly.

  1. 1

    Look before you leap. A dry run shows what would be imported without writing anything.

    bash
    1claw local import .env --dry-run
  2. 2

    Import for real. Existing entries are skipped rather than overwritten unless you say otherwise.

    bash
    1claw local import .env
  3. 3

    If you do want to overwrite what is already there, be explicit about it.

    bash
    1claw local import .env --force
  4. 4

    Export back to .env format when a tool needs a file. Without -o it writes to stdout, so you can pipe it.

    bash
    1claw local export

# or straight to a file your tooling expects
1claw local export -o .env
Watch out

Once a secret is in the vault, delete the .env from the project and add it to .gitignore. Importing without removing the original leaves you with two copies and no improvement.

The import and export pair is deliberately boring, and that is the point: it means adopting the vault does not require changing how any of your tools work. You keep the .env-shaped interface at the edges and stop keeping plaintext files around between runs.

Tip

1claw env run -- <command> goes one step further: it resolves the values and injects them into a child process's environment, so nothing is ever written to disk at all.

Check your understanding

3 questions
1

What does `1claw local import .env --dry-run` do?

2

By default, what happens to a key that already exists in the vault?

3

What should you do with the .env file after importing it?