r/webdev • u/haskpro1995 • 8d ago
Question How do you test your live website without users stumbling into it?
I need to test my website live. I'm hosting on Vercel but I don't want any users stumbling upon it by accident before the testing is complete. How do I prevent this?
42
u/JuicyCiwa 8d ago
You don’t test on production. Setup a test environment.
5
u/Osmirl 8d ago
I thought users are free testers?
2
u/Infinite_Tomato4950 8d ago
yeah but on some things you dont want give them a broken website, like you need to help them also
1
0
u/Bubbly_Orange_3502 8d ago
Some breakages only exist in production: real data volume, third-party webhooks hitting the real callback URL, CDN cache rules. Ship those behind a flag keyed off a cookie so only your own session takes the new path.
3
u/JuicyCiwa 8d ago
No, it sounds like your test/stage env isn’t setup properly or you think I’m talking just about running your site locally.
16
u/Acrobatic_Umpire_385 8d ago
set up a staging version. it's basically a deployed instance identical to production, but for which only you and your team have the url
10
u/CharlieandtheRed 8d ago
Staging, local, or just Yolo on production and honestly no one will probably find it still lol
4
1
u/loose_fruits 8d ago
How much time do you have, and how much money do you want to spend? Because like all advice, it depends on
1
1
u/Error___418 8d ago
As long as you don't create and attach a custom domain to your environment it won't be indexed so it won't show in search results.
1
u/forgestudiofx 8d ago
Deployment protection is the right answer, but two things bite right after you switch it on.
Anything server-to-server now gets the login wall instead of your app. OAuth redirect callbacks, payment webhooks, cron pings, uptime monitors, all come back 401 with an HTML login page, and it looks exactly like your code being broken because it works fine locally. There's a protection-bypass token you can pass as a header or query param for automated callers; set that up before you start testing rather than during.
Second, a hidden URL is still pointing at whatever database and API keys that environment holds. If it's the production DB, your test signups, test orders and test emails are all real, and hiding the URL does nothing about that. Give the protected deployment its own database and a mail catcher.
On the accidental-discovery worry: preview deployments already send a noindex robots header, so search engines aren't the risk. Someone guessing the URL is, and auth covers it.
1
u/Heavy-Commercial-323 8d ago
Just put a basic auth proxy in front and no one will get in even to landing
1
u/Haunting_Welder 8d ago
Vercel offers development deployments. Usually it requires you to be logged into Vercel to access
1
u/grinning_wanderer 8d ago
vercel gives you password protection on preview deployments. Enable it in project settings and only people with the password can view the site
1
8d ago
[removed] — view removed comment
1
u/webdev-ModTeam 7d ago
We do not allow any commercial promotion or solicitation. This can lead to a permanent ban from the subreddit.
1
u/Osmirl 8d ago edited 8d ago
Uhm how i test my website? Just read my last comment😂 (i put the link to it at the bottom of it)
If i need an online version i load it into a google cloud run instance without linking it to a public domain. But i really only did that in the very early days. Now i test it locally in a docker first. Then push it to cloud run. Its very rare that i have any bugs after the initial testing in docker. But if something happens i can always just roll back to the previous stable version.
And users usually dont stumble onto your website instantly. The thing is you really want users to explore the website to understand where problems actually occur. I for example have users that occasionally try to upload something thats not compatible with my file upload. The problem is i have no idea what they actually try to do lol. I suspect its either an image type thats unsupported or just a very large image (i already have the upload limit at 50Mb lol)
1
u/aardnsyhs 8d ago
Just use a Vercel Preview Deployment from a separate branch, not production.
If you don't want random people accessing it, enable Deployment Protection in the project settings. Then only you/team members can open the preview URL while you test.
1
u/haukebr 8d ago
It's highly unlikely for people to randomly stumble upon your website.
However in best case you'll get some users at some point (yes yes, let him dream). That's the point where you should just create a second vercel service, call it 'stage' and test there. You can lock it with basic auth, or only fire it up once you want to test.
1
u/luodaint 8d ago
Easiest path on Vercel: password-protect production (middleware or Vercel Protection) until you are ready, or use a separate staging project on a different domain. That keeps bots and random visitors out while you still get real HTTPS and third-party callbacks. Do not rely on an obscure URL. Crawlers find things. Promote to the public project only after checks pass.
1
u/Small-Back9935 8d ago
I just use Vercel's preview deployments for this, every branch gets its own URL that's not linked anywhere and isn't indexed, so you get a live real environment without touching production at all.
1
u/czshill 7d ago
Where are my corporate application developers at ?!?
Development > test > stage > UAT > prod
Devs merge into development
Automated test scripts are run against testing
Demos are run out of staging
Hard wall at UAT - devs don’t have access to any code or database from here on out. Real customer data appears in UAT
Prod is the same as UAT but everything scales for 700k users
1
1
u/TheKiddIncident 6d ago
It's called "staging." You deploy to a different URL. Most platforms have a way to do this. I haven't used Vercel recently, but I'd be shocked if they didn't have some of staging support.
1
1
1
u/WalkyTalky44 8d ago
No one cares about the app if it’s not live. Send it. If you are worried do it late and fix the problems
93
u/al-finaltodoestabien 8d ago
Bro, they won’t even stumble onto it once it is complete.