Replit Agent: securing an app before you share it

Replit Secrets vs .env: two mechanisms, one habit

Replit offers a dedicated secrets manager (the Secrets tab), encrypted and never included in the project's files. But an agent taking the most direct path to make an integration work sometimes writes the key into a plain .env file instead — an ordinary text file in the project, subject to the same rules as any other file in the repo:

# .env at the project root — not encrypted, not isolated from the code
DATABASE_URL=postgres://user:pass@host/db
STRIPE_SECRET_KEY=sk_live_...

If this file isn't excluded from version control, or if the Repl itself is public, these secrets end up just as exposed as a .env file mistakenly served over HTTP on any other host.

A public Repl exposes its entire source code

A Repl marked public can be browsed file by file by anyone — that's the expected behavior for a project you want to show off or share. The problem shows up when that same Repl still contains real credentials used during development (a test database key that actually points to real data, a third-party service token): the public visibility of the code automatically extends to anything hardcoded in it, secrets included.

The fix

Explicitly ask the agent to use Replit's secrets manager rather than a .env file for any sensitive key, and check afterward where it actually landed:

// reading the value looks identical either way
process.env.STRIPE_SECRET_KEY

// but the key must be defined in Secrets (encrypted, outside the repo),
// not in a .env file committed alongside the rest of the code

Keep the Repl private as long as it holds real credentials, and if a .env file still exists in the project regardless, make sure it's listed in .gitignore and that no route serves it once deployed. Details: Publicly exposed .env or .git and Hardcoded API keys and secrets.

Built an app with Replit Agent that's deployed and publicly reachable? Scan it to check no secret is reachable from the outside.