Is Replit secure? Shipping a Replit app safely

Replit can publish an app with hosting, a database, and auth already attached. The short list is Ship a Replit app. This page is what Replit's own docs say to verify on the way out, and what they do not decide for you. Replit is the directory entry.

Who can open the published app

Replit's publishing overview says the Publishing pane includes who can access the app: Public, Password protected, Workspace only, or Invite only. The private options limit the app to your workspace or to the people and groups you invite. Public means the URL is for anyone who has it.

Pick that setting on purpose. A prototype with test accounts and a real user table should not share an access level. The URL existing is not the same thing as the access setting you wanted.

Secrets, and the two panes that hold them

Replit's Secrets docs say the Secrets tool encrypts API keys, tokens, and database connection strings and exposes them as environment variables, so you do not hard-code them. Hard-coding is how a key ends up in a public Repl, a public git repo, or a screen share. The same page splits Secrets from Configurations. Configurations are for non-sensitive settings such as a log level, a feature flag, or a public URL. A value with a credential is a secret.

Two official pages describe how those values reach the published app, and they do not use the same sentence. The publishing overview says deployment secrets sync from the development environment when you publish or republish. The troubleshooting page says secrets you set in the Project Editor do not automatically carry over, and that you add production secrets in the Publishing pane. Missing production secrets, it says, show up as undefined values, failed API calls, database connection errors, or payment failures.

Open the Publishing pane and read the production values before you share the URL. Do not assume the editor list and the live app match until you have looked. If a production connection string was exposed, Replit's database docs say to regenerate the production database credentials.

The wider key pass, including keys that are public by design and keys that are not, is API keys in the frontend.

Development data and production data

Replit's development-and-production database docs say every app has two databases. The development database is where you and Agent experiment. The production database serves the published app. Agent can change the development database. Agent cannot modify the production database. When you publish, schema changes from development (tables and columns added or deleted) are applied to production.

On current infrastructure, Replit says it creates the production database when you publish, if the development database contains data. On legacy Neon development databases, you create it from the publish settings, and you can choose to copy development data across.

Copy development data only when that data is fit for the live app. Replit's docs say development data can include test accounts, sample records, or incomplete content. After publishing, the editor keeps using the development database, so later development edits do not directly change live rows. Schema changes on the next publish still do.

If this Repl is connected to Supabase or Firebase instead of Replit's database, the built-in split does not apply. Use how to set up Supabase row level security or the equivalent rules on the database the client actually calls. Two auth systems at once is a smell. Pick the one the data rules trust.

The scan Replit runs, and the checks it does not

Replit's publishing docs say it always runs a security scan before publishing. Security Agent combines AI with static analysis. A setting can block publishing when critical vulnerabilities are found. Read the result. A scan that does not block the button has not reviewed your row rules, your webhook signature, or whether user B can read user A's rows.

Do those yourself:

• Create two accounts. As the second, request the first account's rows. Repeat while logged out.
• If you charge with Stripe, the server verifies the webhook. The browser screen that says "paid" is not that check. See the Stripe webhook checklist.
• Put a rate limit on any route that calls a paid model or sends mail.
• Turn on the monitoring Replit offers if you want the downtime email, and add error monitoring if you also want stack traces. Mask anything in those events that could be a secret.

Then run a free passive check on the published URL and finish the pre-launch checklist.

FAQ

Does Publish mean the production database is a copy of what I see in the editor?

Not as an ongoing copy. Replit says the production database is created at publish, schema changes are applied then, and the editor keeps using the development database afterward. You can choose, on legacy Neon setups, to copy development data once. Do that only if the development rows are fit to be live.

Will a secret in the editor be on the published app?

Confirm it in the Publishing pane. Replit's publishing overview says secrets sync when you publish. Its troubleshooting page says editor secrets do not automatically carry over and that you add them in that pane. The live app uses whatever is in the production list, not whatever you remember typing.

Does Replit's security scan replace a review of the data rules?

No. Replit describes it as a scan for vulnerabilities before publish, with an option to block critical findings. It does not establish that a second user is blocked from the first user's rows. That test is still yours. If the database is Supabase, the policies are the control, not the scan.

Can I keep the app off the public internet?

Replit's publishing docs list Password protected, Workspace only, and Invite only alongside Public. Use one of those for a prototype. A password on the app is not a substitute for row rules once real users share one database.

Sources

Checked 26 Oct 2026.

• Replit publishing
• Replit secrets
• Replit development and production databases
• Replit troubleshoot publishing