Can Replit Agent see the values in my Secrets pane?

Yes. Replit Agent has full read access to environment variables defined in the Secrets pane during agent sessions, because that is how it configures database connections, third party API calls, and OAuth flows. Replit's own documentation acknowledges this behavior. Treat any credential you share with an Agent session as readable by the model and any code the model writes back into the project.

If I prefix a Secret with VITE_ does it stay private?

No. Vite, Next.js, and Create React App treat VITE_, NEXT_PUBLIC_, and REACT_APP_ prefixes as a signal to inline the value into the JavaScript bundle served to every browser. The Secret stays encrypted at rest in Replit, but its value is copied into the public bundle at build time. Use a server route to proxy the call instead, and keep the key server side.

Does deleting a key from my code remove it from Repl history?

No. Replit preserves the file history of every Repl, similar to a git log. A credential committed once stays retrievable through the history viewer even after you delete the file or replace the value. The correct response after any exposure is to rotate the key with the provider, then move the project to a private Repl or delete the public Repl outright.

Do Static Deployments support runtime Secrets?

Replit's Secrets documentation states that Secrets are available for all deployment types except Static Deployments. Static sites have no server, so the bundler must inline any value at build time, which puts it in the public JavaScript. If a site needs API keys, switch to Autoscale, Reserved VM, or Scheduled deployment, and call third party services from server side handlers, never from the static client.

Why does Replit discourage creating a .env file?

Replit nudges users toward the Secrets pane because .env files in public Repls have been the largest source of credential leaks in the platform's history. A freeCodeCamp forum thread documents the rollout of the change. You can still produce a .env through the Shell, but doing so reintroduces the exact failure mode the platform tried to remove. Stay with the Secrets pane.

Does Replit Agent handle environment variables securely?

You are about to ship a Replit Agent built app and a small worry keeps coming back: when the Agent wired up Stripe, Supabase, and an OpenAI key, did it put the values somewhere safe, or did it copy them straight into the bundle that ships to every browser? The honest answer is that Replit gives you the right vault, but Replit Agent does not always use it correctly.

Short answer

Replit stores credentials added through the Secrets pane as AES-256 encrypted environment variables, available to your code through process.env or os.getenv(), per Replit's Secrets documentation. Replit Agent can read them while it builds. The vulnerability shows up when Agent writes the key back into the project: as a fallback in a config file, as a VITE_ prefixed variable that the bundler inlines into the client bundle, or as a literal string in a generated React component. Encryption holds. The leak comes from where Agent decides to place the value during generation.

What you should know

Secrets are encrypted at rest but readable by Agent. Any prompt you give Replit Agent can cause it to print, log, or paste the value into a file. Encryption only protects the storage layer.
.env files are not Secrets. A file called .env in your project is plain text, included in source, and visible to anyone who reads a public Repl.
Frontend bundlers inline anything prefixed with VITE_, NEXT_PUBLIC_, or REACT_APP_. A key with that prefix lands in the JavaScript every browser downloads, even if it sits in the Secrets pane.
Static Deployments cannot read Secrets at runtime. Build time inlining is the only path, which forces secrets into the bundle for static sites.
Repl history outlives the move to Secrets. A key removed from a file but committed earlier remains visible in the project history.
Free Repls are public by default. Scraping bots discover credentials within minutes of commit.

Where does Replit Agent actually store your secrets?

Replit has two surfaces for credential storage: the Secrets pane and .env files. They are not equivalent. The Secrets pane encrypts each entry at rest with AES-256 and surfaces the values as environment variables to your running process, according to Replit's Secrets documentation. .env files are plain text, live inside your project tree, and ship with every Repl fork.

Replit Agent will reach for Secrets when you ask it to connect a third party service, but if your prompt mentions the key directly or a tutorial it copied uses .env, Agent may write the value into a tracked file instead. Storage choice depends on how Agent interpreted your prompt, not on a switch you flipped. Open the Secrets pane and the project file tree side by side, and confirm that no .env, .env.local, or config.json contains a key you also defined as a Secret. A duplicate is a leak waiting to be indexed.

Why does Replit Agent sometimes hardcode keys into client code?

The cause is the gap between server side and browser side environment variables. Frameworks like Vite, Next.js, and Create React App require a prefix (VITE_, NEXT_PUBLIC_, REACT_APP_) for any variable that should be available in browser code, and they inline those values into the static JavaScript bundle at build time. Agent, when wiring up a frontend call to Stripe or OpenAI, often defaults to that pattern because the resulting code runs immediately in the preview window.

A 2025 analysis from VibeAppScanner described the pattern in plain terms: Replit's Agent often generates frontend JavaScript that calls third party APIs directly from the browser, and even if the key is stored in Secrets, the Agent may expose it by embedding it in client side JavaScript. The consequence is severe: every visitor can read the key in the Network panel or the bundle source. The fix is a backend proxy, a Replit deployment with serverless endpoints that hold the key on the server and expose only a narrow API to the client.

How do I spot a leaked secret in my Repl right now?

A five minute pre-submission audit catches most leaks. Start with git log --all -p | grep -iE "sk-|api_key|secret" inside the Shell to surface any credential ever committed. Then list every environment variable currently shipped to the client by running your production build and grepping the output bundle for the first eight characters of each Secret value. Open .replit and replit.nix and look for hardcoded values in build commands.

Finally, scan the running app: open DevTools, watch the Network tab during a session, and confirm that no request from the browser sends an Authorization: Bearer header containing a server side key. If any of these checks light up, rotate the key at the provider first, then commit the cleanup. Replit's secret scanner covers known token patterns automatically but cannot see custom token formats, so the manual grep still matters.

What happens to secrets after deploy and in public Repls?

Deployment behavior differs by type. Autoscale, Reserved VM, and Scheduled deployments receive the Secrets you defined on the Repl as runtime environment variables, per the Replit Secrets documentation. Static Deployments do not have a runtime, so the only way a key reaches the bundle is build time inlining, which puts it directly in the public JavaScript.

For public Repls, the structural reality is harder: the source tree is world readable, search bots index it, and any file (including .env, shell history at ~/.bash_history, and stray notebook outputs) is fair game. The Repl history preserves earlier commits even after you delete a file, so a key once committed stays retrievable through the history viewer. The minimum hygiene before publishing: rotate every key touched during Agent sessions, move to a private Repl, and delete the Repl entirely if a credential ever sat in a public commit.

What does Agent get right, and where does it still miss?

Agent does some things consistently well and others poorly. The table below summarizes the patterns to expect in generated code, the risk if you accept them as is, and the safer pattern to ask for explicitly.

Generated pattern	Replit Agent default	Risk if accepted as is	Safer pattern
Backend API call (Node, Python)	Reads from `process.env` or `os.getenv`	Low, if key is in Secrets	Confirm Secret name matches and file is server side
Frontend call to third party API	Inlines via `VITE_` or `NEXT_PUBLIC_` prefix	High, key in client bundle	Add a server route that proxies the call
`.env` file generation	Sometimes creates `.env` with placeholder values	Medium, future edits may add real values	Delete `.env`, use Secrets only
Hardcoded fallback	Occasionally writes `apiKey		"sk-..."`
Build script in `.replit`	May echo env vars into logs for debugging	Medium, logs may be screenshared	Remove debug echoes before deploy

The table is a starting checklist. Run through it before every deploy, and ask Agent to refactor any row marked High or Critical before you publish.

What to watch out for

A few patterns trip even careful builders.

Console logs left from Agent debugging. Agent often inserts console.log(process.env.OPENAI_KEY) while diagnosing a failed call. The log line ends up in browser logs if it sits in client code, and in deploy logs (which often get shared via screenshot in support tickets) if it sits server side.
The "I will fix it after launch" reflex. Once a key is committed to a public Repl, rotation is the only safe response. Removing it from the file does not remove it from history. The Replit API key safety post is explicit on this point.
Forgetting that Account Secrets are linkable. Account level Secrets are visible to any Repl you link them into, including throwaway Repls you spin up to test ideas. A test Repl that imports the production OpenAI key is one prompt away from leaking it.
Assuming the Replit secret scanner has your back. It catches popular formats (OpenAI, Stripe, AWS) but ignores custom JWT signing keys, Supabase service role keys with unusual prefixes, and webhook secrets you defined yourself.

For a fuller external audit, PTKD.com is one of the platforms that scan compiled mobile builds (APK, AAB, IPA) for credential leakage in the bundle, including the JavaScript shipped by wrappers like Capacitor, Cordova, or React Native when teams package a Replit web app for mobile distribution.

Key takeaways

Replit Secrets are encrypted at rest, but Replit Agent has full read access during build and may write the value back into your code.
The most common leak shape is a VITE_, NEXT_PUBLIC_, or REACT_APP_ prefixed key inlined into the browser bundle. Audit your build output before deploy.
Public Repls and Repl history are world readable. Rotate any key that ever touched a public commit; do not assume deletion is enough.
Static Deployments cannot read Secrets at runtime; if you need credentials, switch to a server side deployment type and proxy third party calls through it.
Some builders run an external pre-submission scan with platforms like PTKD.com for credential leakage in the final mobile bundle, as a second pair of eyes before publishing to App Store or Google Play.