Where to store API keys: server, CI, and local dev

Store an API key only where your own code runs, on machines you control. In production, that's an environment variable filled from a secret manager or your host's secret settings; in CI, the pipeline's secret store; on your laptop, an environment variable or a git-ignored .env file. Never put it in frontend code, a mobile app, a repository, a ticket or a screenshot: whatever ships to a browser or phone, its user can read.

The Sume rules come from its Authentication, API keys and CLI security docs; tool behavior is quoted from the GitHub Actions, Vite, Git, Node.js and Python docs. All were read on 2026-09-28.

Which places are safe for an API key?

Sume's safety rules name them:

How do I store a key in production?

Keep the value in a secret manager or your host's secret settings, and hand it to the process as an environment variable. Sume's docs set the key as a server-side variable, export SUME_API_KEY="sume_live_...", that your code reads at runtime.

Save the key the moment you create it. Sume's dashboard reveals the full secret only when a key is created, and API responses afterwards show key metadata such as its prefix and scopes, never the full secret. If you lose it, create a new key.

Where do I store API keys in a React app?

Nowhere in the app. Code that runs in the browser ships to every visitor, so a key in it is public. Vite's docs, for example, say VITE_* variables should not contain sensitive information such as API keys, because their values are bundled into your source code at build time; they point to a backend server or serverless functions instead.

Sume's docs give the same pattern: browser and mobile clients call your backend, and the backend attaches the Sume key after it validates the input and enforces your own authorization. CORS error calling the Sume API from a browser shows that proxy.

Where do I keep API keys locally, in Python or Node?

In an environment variable, or a .env file that git ignores, loaded at runtime rather than pasted into code:

• Python reads the process environment through os.environ, a mapping of strings, so os.environ["SUME_API_KEY"] returns the key.
• Node.js exposes the environment as process.env, and its --env-file=file option loads a .env file into it.
• Ignore the file before the first commit. A gitignore file keeps untracked files untracked, but files git already tracks are not affected: stop tracking one with git rm --cached. Treat a key that was already committed as exposed, and rotate it.
• If you use the Sume CLI, it keeps local configuration in ~/.sume-com/config.json. Its docs say never to print or commit that file or SUME_API_KEY.

How do I store API keys in CI?

In the CI system's secret store. In GitHub Actions, a secret is a variable you create for an organization, repository or environment, passed to a step as an environment variable. GitHub redacts secrets printed to workflow logs but says the redaction is not guaranteed, so never echo the key. Secrets other than GITHUB_TOKEN aren't passed to the runner when a workflow is triggered from a forked repository.

steps:
  - shell: bash
    env:
      SUME_API_KEY: ${{ secrets.SUME_API_KEY }}
    run: |
      curl https://api.sume.com/v1/me -H "Authorization: Bearer $SUME_API_KEY"

What if a key ends up somewhere it shouldn't?

Rotate it: create a replacement key, deploy it to your server, verify GET /v1/me, then revoke the old key from the dashboard. Exposed API key? covers the cleanup. Treat your webhook signing secret the same way: Sume's docs say to store it the way you store the API key.