Short answer
To test a Replit app, let Replit Agent's App Testing and security scan run, then publish and test the replit.app URL in a browser with a test account. Replit's development URL needs a Replit login, so test the published app. TestOptim AI tests it signed in, covers negative and edge cases, and re-runs after each publish.
- Replit separates development and production databases, so the published app has different data from the one you built against.
- Secrets set in the editor do not reach the published app automatically; missing ones break sign-in, payments and database calls.
- Replit Auth signs your users in with Replit accounts; give TestOptim a separate Replit account made for testing.
On this page
How a Replit app is built and hosted
Replit Agent builds full-stack web apps with a frontend, a backend, API routes and a Postgres database. Replit does not fix one framework, though React with an Express backend is common in Agent projects.
While you build, the app runs at a development URL ending in replit.dev. It is private, needs a Replit login, changes between sessions and is only up while you work, so an outside tester cannot use it. Published apps run at your-app.replit.app or a custom domain, with access set to public, password protected, workspace only or invite only. Choose public for testing; TestOptim cannot get past Replit's own access controls.
For sign-in, Agent sets up Replit Auth, where your users sign in with Replit accounts through Google, GitHub, X, Apple or email, or Clerk, which gives your app its own accounts.
What Replit already tests in your app
- App Testing: Agent tests the app in a real browser, covering UI, flows, API and database calls, then fixes what it finds. It is off in Free mode, available in Power and Max modes, and asks you to take over when it reaches a login.
- Security scan on publish, with an option to block publishing on critical vulnerabilities, plus deeper code scans and an AI penetration test of the preview on paid levels.
- Package firewall that blocks known malicious packages, on by default.
Replit has the strongest built-in checks of the major builders. What they leave open is the published app: its production database, its production secrets, and its signed-in flows tested on a schedule without someone at the keyboard.
Bugs to check in a Replit app
- Secrets missing in production. Secrets in the editor do not carry over to the published app, which leaves values undefined and breaks database, sign-in or payment calls. TestOptim records the failed requests and 5xx responses this causes.
- Works in development, broken when published. Replit's docs list hard-coded
localhostaddresses, aDATABASE_URLpointing at development, an app not listening on the right port, and migrations that never ran in production. - Schema changes at publish. Agent's development schema changes, such as dropped or renamed columns, are applied to production when you publish. Test the published app after every publish that changed data.
- Sign-in on a new custom domain can fail with Replit Auth until you republish.
How to test a Replit app with TestOptim AI
- Publish with public access, and use the
replit.appaddress or your custom domain. Open the URL in a private browser window. If you see your app without signing in to the builder, TestOptim can reach it too. - Create a test account. With Clerk or your own sign-in, use email and password. With Replit Auth, create a separate Replit account for testing with email sign-in.
- Create a TestOptim project with the URL and add the account as a credential profile. If sign-in asks for an emailed code, exploration pauses for you to enter it.
- Explore, generate and run, then paste each issue's steps into Agent to fix it, publish, and mark the issue fixed to re-run its test.
- Re-test after every publish. Start a run from your workflow with an API key, or schedule one.
Testing the published app writes to the production database. Use a test account, and avoid testing actions that change other users' data.
Frequently asked questions
Does Replit Agent test my app?
Yes, with App Testing in Power and Max modes: Agent tests the app in a browser and fixes issues. It runs while you build, asks you to take over at login walls, and is off in Free mode, so signed-in flows on the published app still need testing.
Why does my Replit app work in development but not when published?
The common causes are secrets that were set only in the editor, a database URL pointing at the development database, hard-coded localhost addresses, and migrations that never ran in production. Check the published app's secrets first, then its logs.
Can TestOptim test my Replit development URL?
No. Replit's replit.dev development URL is private, needs a Replit login and is only up while you work. Publish the app with public access and test the replit.app address or your custom domain.
How do I test a Replit app that uses Replit Auth?
Your users sign in with Replit accounts, so create a separate Replit account for testing, with email sign-in, and add it to TestOptim as a credential profile. If Replit asks for an emailed code, exploration pauses and emails you so you can enter it.
Does publishing my Replit app change my production database?
It can. Replit applies the schema changes Agent made in development to production at publish, including dropped or renamed columns. Review the changes before you publish, then test the published app.
Which access setting should my published Replit app use for testing?
Public. Password protected, workspace only and invite only all put Replit's own sign-in in front of your app, and an outside tester cannot get past it. If the app must stay private, test a separate public copy with test data instead.
Sources
Platform facts were checked against these pages on 22 October 2026. Builders change quickly, so check them again before relying on a detail.
More Vibe-coded apps guides
- How to test a vibe-coded app before you launchHow to test a vibe-coded app from Lovable, Bolt, Replit, Base44 or v0: the bugs AI app builders leave, what their own checks miss, and a launch checklist.
- How to test a Lovable app before you launchHow to test a Lovable app: what Lovable's security scan and browser testing cover, the Supabase RLS and sign-in bugs to check, and how to QA lovable.app.
- How to test a Bolt.new app before you launchHow to test a Bolt.new app: the localhost redirect, open database policies and missing env vars to check, and how to QA bolt.host.
- How to test a Base44 app before you launchHow to test a Base44 app: what the Testing Agent and Security Scan cover, why sign-in can only be tested once published, and how to QA base44.app.
- How to test a v0 app before it reaches productionHow to test a v0 app on Vercel: protected preview deployments, NEXT_PUBLIC_ secrets, env vars that differ by environment, and how to QA production.