API Keys & .env

Never put a key in package.json

provider.apiKeyEnv in your config is the name of an environment variable, never the key's value. package.json gets committed to git — anything written there ends up in your repo's history, and on GitHub if the repo is public, forever (rewriting history doesn't reliably undo a leaked secret once it's been pushed).

{
  "provider": {
    "name": "deepl",
    "apiKeyEnv": "DEEPL_API_KEY"
  }
}

.env is loaded automatically

Node doesn't read .env files on its own — that's not something the runtime does for you. lingosync's CLI loads one for you: if a .env file exists at your project root, it's parsed and merged into process.env before anything else runs, without overriding a variable you've already exported. An explicit export (or an inline DEEPL_API_KEY=... npx lingosync sync) always wins over what's in .env.

# .env — add this to .gitignore
DEEPL_API_KEY=your-key-here

npx lingosync sync

No need to export anything by hand for local development.

Make sure .env is gitignored

This one's on you, not lingosync — but it's worth saying explicitly: add .env to your project's .gitignore if it isn't already there. lingosync never writes to .env and never reads or logs the key's value anywhere except to hand it to the provider's HTTP client.

CI / production

In CI, set the environment variable through your CI provider's secrets mechanism (GitHub Actions secrets, etc.) instead of committing a .env file. lingosync picks up an already-exported variable exactly the same way — the .env loader is a local-dev convenience, not a requirement.