I want to test my website in a real hosted environment before the finished version is available to the public. It's deployed on Vercel, but I'd like to prevent accidental visitors from accessing it while I test. What setup or protection should I use?
5 Answers
If you don’t attach a public custom domain, a preview deployment is unlikely to be discovered through search, and preview deployments generally send no-index signals. Still, authentication or a basic-auth proxy is better because someone could guess or obtain the deployment URL. Vercel’s development and preview deployments can also restrict access to logged-in project members.
Protecting the URL is only part of the solution. Use a separate database, API keys, and email-testing service for staging so test accounts, orders, emails, or destructive operations can’t affect real users. A hidden or password-protected deployment connected to production data is still risky.
Deployment protection works well, but remember that it can also block server-to-server requests. OAuth callbacks, payment webhooks, scheduled jobs, and monitoring services may receive a login page or a 401 response instead of reaching your app. Configure an approved bypass token or equivalent access method for those services before testing.
For a simple setup, use a separate staging project or branch, enable password protection, test with staging services, and deploy to the public production domain only when it’s ready. For most projects, users won’t randomly find an unpublicized site, but access controls are safer than relying on obscurity.
The usual approach is to create a staging or preview deployment that mirrors production, then protect it with Vercel Authentication or password protection. Keep production separate and promote the staging build only after testing. A local environment is still useful for most development, but staging can reveal hosting-specific issues.
A good workflow is development locally, then a staging branch or preview deployment, and finally the production branch.