Storing and Using API Keys Safely with Replit Secrets
How to add, read, and verify environment variables with Replit Secrets — plus the sharing, size, and rotation limits you need to know before trusting it with real credentials.
28 Sept 2025, 01:26 UTC

The problem: credentials don't belong in your Repl's code
Every Replit project eventually needs an API key, database password, or token. The tempting move is pasting it into a config file — but anything in your Repl's files is part of the codebase. It shows up in version history, and on a public Repl it's visible to anyone with the link. Replit Secrets is the built-in answer: encrypted key-value storage that is injected into your program's environment at runtime and never written into your source files.
This guide walks through adding a secret, reading it from Node.js or Python code, verifying it works, and understanding the limits that matter before you rely on it — including the sharing behavior that surprises most teams.
Prerequisites
- A Replit account and a Repl you own or have edit access to.
- The credential you want to store (for example, an API key from a third-party service).
- Basic familiarity with your Repl's language runtime — the examples below use Node.js and Python, but the mechanism is identical in any language that reads environment variables.
No packages, billing tier, or special configuration are required; Secrets is available in the standard IDE.
Step 1: Add the secret in the Secrets tab
Open your Repl and find the Secrets tool in the left-hand workspace sidebar (it may be under the Tools section, represented by a padlock icon). Click New Secret and enter:
- Key:
WEATHER_API_KEY— use uppercase with underscores; this exact string becomes the environment variable name. - Value: the actual credential, pasted exactly as issued.
Save it. The value is stored encrypted on Replit's servers and injected into your program's environment every time the Repl runs. Two hard limits apply: a single secret value can be at most 4 KB, and total secret storage per Repl is capped at 1 MB. If a save is rejected, an oversized value is the first thing to check — large service-account JSON files sometimes exceed the per-secret limit, in which case store the credential differently (for example, as a file uploaded outside version control) or use a smaller token.
Step 2: Read the secret from your code
The key name must match exactly, including case. In Node.js:
// index.js
const apiKey = process.env.WEATHER_API_KEY;
if (!apiKey) {
throw new Error("WEATHER_API_KEY is not set — add it in the Secrets tab");
}
// use apiKey in your request headers, never log itIn Python:
import os
api_key = os.getenv("WEATHER_API_KEY")
if not api_key:
raise RuntimeError("WEATHER_API_KEY is not set — add it in the Secrets tab")The explicit missing-key check is worth the two lines: without it, a typo in the key name fails later as an opaque authentication error from the API instead of an immediate, clear message.
Step 3: Verify the secret is actually available
Run the Repl. If the program starts without the "not set" error, the variable was injected. For a direct check, open the Repl's Shell (not the language console) and run:
env | grep WEATHER_API_KEYThis prints the variable name and value as the shell sees them. Run it only as a one-off diagnostic — and be aware the value will appear in the shell output on screen, so don't do this while screen-sharing. A safer confirmation that avoids printing the value:
[ -n "$WEATHER_API_KEY" ] && echo "set" || echo "missing"Finally, confirm the credential is not in your codebase: search the Repl's files for the key's value. It should appear nowhere — that is the whole point of the feature.
Limits and risks to plan around
| Behavior | What it means for you |
|---|---|
| Secrets are visible to every collaborator with edit access | Sharing settings are your only access control. Don't put production credentials in a Repl shared broadly or used for teaching. |
| Secrets are not in Git history or the public Repl page | Forking or publishing the Repl does not carry the values, but always double-check before making a Repl public. |
| Values can only be changed in the Secrets UI | Key rotation is a manual step; scripts cannot update secrets from inside the Repl. |
| Printing a secret exposes it in logs and the console | Never console.log or print a secret, and scrub it from error messages before re-raising. |
The collaborator point deserves emphasis: anyone who can edit the Repl can open the Secrets tab and read every value. If you need per-person access control or audit trails, you have outgrown this feature and should look at a dedicated secrets manager.
Recovery: fixing common problems
- Program reports the variable is missing: check the key name for typos and case mismatches, then stop and re-run the Repl — environment variables are injected at process start, so edits to secrets don't reach an already-running process.
- Wrong value was saved: open the Secrets tab, edit the entry, and restart the Repl. No code change is needed.
- Secret was accidentally committed or printed: treat it as compromised. Revoke it at the provider, issue a new one, and update the Secrets entry — deleting the log line does not undo exposure.
- Secret rejected as too large: confirm the value is under 4 KB and total storage under 1 MB; trim whitespace accidentally copied with the value.
Note that Replit's interface and limits can change; if a limit or tab location described here doesn't match what you see, check Replit's current documentation for the Secrets feature before assuming something is broken.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.