A Repl and a Deployment are not the same surface
This note is a narrow follow-up to the general Replit launch post, not a repeat of it. The subject here is one distinction that quietly decides what the public can reach: a development Repl and a Replit Deployment are two different trust surfaces, and people conflate them.
A Repl is a development workspace. It is the editor, the console, and usually a live dev preview of your app, all wired together so you can build and see changes immediately. A Deployment is the production-facing artifact: the build you publish to a stable URL, served as a static site, an autoscale service, or a reserved-VM service depending on the type you pick. Same project, two different things in front of the visitor.
The security-relevant part is that the dev preview and the Deployment can return different content. The preview is a developer convenience: it may carry consoles, hot-reload tooling, verbose errors, and whatever you have wired up in the workspace at that moment. The Deployment is the snapshot you chose to publish. The concrete risk is sharing the wrong one, so an audience you invited for the production app lands on the development surface instead.
Observable from outside: which URL you hand out, and what that URL returns to a logged-out visitor. Only readable in your own setup: which secrets are scoped to the Deployment versus the workspace. Keep those two questions separate as you check.
Why builders ship the wrong URL
The dev preview URL is the one you stare at all day. While you build, the preview is where the app runs, so it is the link already in your clipboard, your browser history, and your last message to a teammate. When the moment comes to share, the path of least resistance is to paste the URL you already have, which is the development one, not the Deployment URL you may not have generated yet.
AI-assisted builds make the slip easier, not harder. The assistant gets you a working preview fast, and a working preview feels finished. Nothing in that fast path forces the question of which artifact a stranger should actually reach. So the development surface gets shared not because anyone decided it was the right one, but because it was the URL in hand and it loaded.
- The preview URL is what you see during the whole build, so it is the default thing to copy.
- A working preview looks done, which hides that the published Deployment is a separate artifact you may not have created or checked.
- Dev-only conveniences (consoles, hot reload, verbose error pages) live on the development surface by design, and they are exactly what you do not want a public audience to land on.
Confirm which URL the public hits
You can settle this on your own project, from outside, with no attack. The goal is to know exactly which URL you will share and what it returns to someone with no session.
First, separate the two URLs. In a logged-out browser (a private or incognito window guarantees no session carries you past a check), open the development preview URL and open the published Deployment URL side by side. If you have not created a Deployment yet, that is itself the finding: there is no production artifact to share, and the only link you have is the development one.
The point of running these against the Deployment URL specifically: that is the artifact the public will reach, so it is the one whose responses matter. A clean dev preview tells you nothing about what the published build returns, and vice versa.
- Suspicious result: the link you were about to share is the development preview, or the Deployment URL still serves a dev-style page with a console, hot-reload tooling, or a stack-trace error page.
- Safer result: the Deployment URL serves the published build, and the dev preview is a URL you keep to yourself.
- Same checks on the Deployment URL regardless of type. Whether it is static, autoscale, or reserved-VM, the visitor-facing questions are identical: request a route that errors and confirm you get a clean error page, not a verbose stack trace; open DevTools and read the Network tab and loaded scripts for secret-shaped strings such as sk_live, AKIA, or a Bearer token; probe obvious file paths like /.env, /.git/, /uploads/, and any export directory and confirm a 404; and request any admin, debug, or internal path with no login and confirm a redirect or a 401/403 rather than the page itself.
Treat the Deployment URL as the only public door
The habit that closes this is simple to state: the Deployment URL is the only thing the public should reach, and the dev preview stays private. Two controls back that up, each scoped to what it actually does.
Neither control "makes the app secure." They make sure the right surface is the public one and that its secrets are scoped correctly. The route, header, and exposure checks in the section above still have to pass on the Deployment URL itself, and authorization between users and your business logic still need a manual read of your own code. Treat the broader private-to-public risks in the general Replit launch note as the companion checklist to this one.
- Generate and share the Deployment URL, never the development preview. This makes sure the audience lands on the published artifact, with dev-only tooling and verbose errors left on the workspace side. It does not by itself remove a secret or close a route; it only fixes which surface the public hits.
- Scope secrets to the Deployment, not just the workspace. Secrets a build needs at runtime should be set for the Deployment and read server-side; a value that only exists in the development workspace can mean the published build behaves differently than the preview you tested. Confirm the secrets the Deployment uses are the ones you intend, and confirm none of them ship in client-side JavaScript. A publishable or anon key is designed to be public; a live secret key is not.
Where a Launch Check fits, and what it does not prove
VibeCodeGuard's Launch Check scans the deployed production URL for header and exposure signals that apply regardless of deployment type. It looks at the public artifact you point it at, so point it at the real Deployment URL, not the dev preview. Against that URL it surfaces secret-shaped strings in the client bundle, missing or weak security headers, exposed build and deploy artifacts, and openly reachable debug routes, with severity and fix guidance for each.
The dependency is yours to get right: the scan inspects whatever URL you give it. Aim it at the development preview and it tells you about the wrong surface. Aim it at the Deployment URL and it maps to the observable checks above, run from the same logged-out vantage point an outsider would have.
Practical next step: open an incognito window, confirm the link you plan to share is the Deployment URL and not the dev preview, run the route and exposure checks against it, then run a focused Launch Check on that same Deployment URL before sharing it publicly.
A clean Launch Check means the public artifact it inspected did not expose those specific signals, and it is only as relevant as the URL you submitted. It does not read your workspace, your server-side logic, or your secret scoping, and it does not cover authorization or business logic. Treat it as the outside-in half of the launch review on the surface that actually faces the public.
> launch check
Scan the public surface before launch.
Get severity, evidence, and practical fix guidance for the checks VibeCodeGuard can run from the outside.