QAlaunch

Replit app stops when I close the tab: how to keep it running

The link you shared is almost certainly the development URL, the one ending in replit.dev. Replit says development URLs are only live while you actively work on the app, are private by default, and can change when you reopen the project. To keep a site running for visitors, publish it from the Publishing pane and share the replit.app address or your custom domain instead.

Opens your site in a real browser on desktop and phone. Free, about two minutes, no signup. Full report from $19.

What you'll see

While the Replit workspace is open, the preview link works on your phone and for friends. A while after you close the tab, the same link shows an error, asks people to sign in, or stops responding. The next day the address in the preview may even be different from the one you sent out.

Why it happens

1. You shared the development URL

The replit.dev address is meant for testing while you build. It depends on your workspace being active, it requires authentication by default, and Replit does not promise it stays the same between sessions.

2. The app was never published

Publishing creates a separate production copy of the app with its own URL and its own secrets. Until you do that, there is no copy that runs independently of your editor.

3. The deployment type does not match the app

Autoscale deployments scale to zero when idle, which is fine for websites but not for a bot or worker that must stay connected all the time. Those need a Reserved VM.

How to fix it

  1. Check the link you shared. If it contains replit.dev, it is the development URL and will not stay up on its own.
  2. Click Publish in the workspace and pick a deployment type in the Publishing pane: Static for plain HTML and front-end builds, Autoscale for most web apps with a server, Reserved VM for always-on servers, bots and websocket apps, Scheduled for jobs that run on a timer.
  3. Before publishing, copy every secret the app needs into the deployment secrets. Development secrets do not carry over to the published app.
  4. When the publish finishes, copy the production URL from the Publishing pane (it ends in replit.app) or connect your own domain under Publishing > Domains.
  5. Replace the old replit.dev link everywhere you posted it: social bios, emails, QR codes and any webhooks that pointed at it.
  6. Check pricing for the deployment type you chose in Replit’s current docs, since plans and included usage change.

Prompt to paste into Replit

Prepare this app for publishing on Replit. Make sure the server listens on 0.0.0.0 and the port from the PORT environment variable, that the homepage responds within a couple of seconds, and that any file data the app writes is stored in the database instead, because the published file system resets on each publish. List every secret the published app needs.

How to check it's fixed

  • Close Replit completely, wait half an hour, then open the replit.app URL or your domain in a private window on your phone over mobile data.
  • Open the same URL the next day and confirm the address and content have not changed.

What a QAlaunch scan shows for this

  • A sign-in screen, error page or unreachable site on the scanned URL instead of your homepage.
  • A missing title and description, which happens when the scan is reading a Replit holding or login page rather than your app.
  • Slow server response on the first request after an idle period, from the PageSpeed audit.

See exactly what a full report contains in the sample report.

Frequently asked questions

What happened to Always On?

Replit replaced the old Always On toggle with Deployments, now called Publishing. Older blog posts that tell you to ping your repl with an uptime monitor describe a setup that no longer applies to published apps.

Is Autoscale or Reserved VM right for a website?

For a normal website or web app, Autoscale is usually enough: it scales to zero when idle and wakes on the next request. Choose Reserved VM when something must run continuously, such as a Discord bot or a websocket server.

Will my data survive republishing?

Files the app writes to disk on a published deployment are reset on each publish. Keep anything that must persist in Replit’s database or another external store.

Done for you · not automated

Rather have a QA engineer test it by hand?

If this is a site you're launching or handing to a client, I'll go through it by hand, including the Replit-specific issues a scan can't reach, like logged-in flows.

$299one-time · 3 business days
  • Up to 10 key pages tested by hand, not a scan
  • Every flow a customer uses: forms, sign-up, checkout, booking
  • Real mobile and desktop browsers
  • A written report in plain language, with screenshots
  • A 15-minute call to walk you through it
  • 10 years of professional QA experience

Tell me about your site and I'll reply personally, usually the same day.

No payment now. I'll confirm scope and price first.

Related fixes

More for Replit: all Replit fixes · Replit testing

Written by Waqas Ahmad, QA engineer with 10 years of professional testing experience. Last checked October 26, 2026.

Sources: Replit docs: development URLs · Replit docs: deployment and publishing help · Replit docs: publishing troubleshooting