Protect Your Vercel Site with Login

Introduction

30 Second Summary

A half-finished website can escape into the world the moment its link becomes public. Search engines can index it before you are ready to share it.

In this project, you will deploy your own site with Vercel. You will protect its production URL with Vercel Authentication while keeping one preview open through a Deployment Protection Exception.

What You'll Build

In a private browser window, your production URL asks for a login while your chosen preview opens straight away.

By the end of this project, you'll have:

• A protected production URL that shows the Vercel login screen in a private browser before revealing your site after you sign in.
• A shareable preview URL that opens directly without asking visitors to log in.
• Command-line proof that the production URL and preview URL return different status codes and headers.
• Secret Mission: an optional challenge to push your access-control skills further.

Are There Any Prerequisites?

You need accounts for GitHub and Vercel. You also need a small site in a GitHub repository.

Before We Start

A protected deployment still needs a site to protect. Your GitHub repository gives Vercel the files it needs to publish that site.

This preparation step connects your accounts. It also confirms that your computer has the tools needed for the browser checks and command-line tests ahead.

In this step, get ready to:

• Connect your GitHub account to Vercel.
• Prepare the local tools used throughout the project.
• Create a static site repository that Vercel can import.

Connect your accounts

Vercel can import a repository after your Git provider is connected. Using GitHub as your Vercel login connection keeps that relationship in one account flow.

• Complete GitHub's account flow through the GitHub homepage.
• Confirm that your GitHub homepage shows your signed-in account.

Your GitHub account is ready to own the repository you create later in this step.

• Open the Vercel sign-up page.
• Select Continue with GitHub.

The authorization request can feel sensitive because it connects two accounts. Review the requested access before you approve it.

• Review the GitHub access requested by Vercel.
• Authorize Vercel to access your GitHub account.
• Confirm that you reach your Vercel dashboard.

Why connect GitHub now?

A Git provider connection lets Vercel import your repository in the next step. The connection also becomes a login method for your Vercel account.

Later checks need a clean browser session. A private window prevents an existing Vercel session from silently passing the login wall.

• Open a private browsing window through your browser's menu.
• Confirm that the window shows your browser's private browsing indicator.

Check your local tools

Git records the identity attached to your commits. The curl command lets you inspect a deployed URL without relying on the browser.

• Press Cmd+Space on macOS or the Windows key on Windows to open system search.
• Type Terminal on macOS or PowerShell on Windows. Press Enter.
• Check whether Git and curl are available by running these commands:

git --version
curl --version

What do these commands check?

• The first command prints the installed Git version when Git is available.
• The second command prints the curl version plus its supported protocols and features.

✔️ I see both version results

That confirms both commands are available. Your terminal is ready for the deployment checks later in the project.

ⓧ One or both commands are unavailable

Install only the tool named as unavailable by your terminal.

• Install Git through the official Git downloads page if the Git check failed.
• Install curl through the official curl downloads page if the curl check failed.
• Restart your terminal after the installation finishes.
• Repeat the two checks shown above.

Still missing a command?

Confirm that the installer completed before restarting your terminal. Some systems do not make a newly installed command available to terminal windows that were already open.

If the command is still unavailable, help me troubleshoot my local Git or curl installation.

Every Git commit stores an author name and email address. Configuring those values now keeps your repository history tied to the identity you expect.

• Configure your Git identity by following the Your Identity instructions in Git's official setup guide.
• Confirm that Git saved your configuration by running this command:

git config --list

What does this command show?

Git lists the configuration values it can currently find. Your output should include values for user.name and user.email.

You should now see your chosen name beside user.name. You should also see your chosen email beside user.email.

Missing your Git identity?

Return to the identity section of the setup guide. Confirm that you entered both values before repeating the configuration check.

If either value remains missing, help me configure my Git author name and email.

Create the deployment repository

Vercel needs a committed web entry point before it can build your deployment. You will create a repository with a starter index.html page on its default branch.

• Return to your signed-in GitHub account.
• Select New repository from the create menu in the upper-right corner.

You should now see GitHub's repository form.

• Select your personal account from the Owner menu.
• Enter login-wall-site in the Repository name field.

GitHub should show that the repository name is available under your account.

• Select Private for the repository visibility.
• Turn on Add README.

The form now shows a private repository that starts with a README file.

• Select Create repository.

Good progress. Your new repository now has its first commit and a default branch.

Why start with a README?

A README initializes the repository immediately. That gives GitHub a default branch where you can commit the web page.

• Select the Add file menu above the repository file list.
• Select Create new file.

GitHub opens a file editor inside your repository.

• Enter index.html in the file name field.
• Open the official GitHub starter web page guide.

The guide includes a complete starter HTML page under its section for adding a starter web page.

• Copy the starter HTML shown in the guide.
• Return to the GitHub file editor.
• Paste the starter HTML into index.html.

The editor should now contain a complete HTML document with a heading and a paragraph.

• Select Commit changes.

GitHub opens a dialog where you can choose the destination for the commit.

• Keep the default option that commits directly to the main branch.
• Select Commit changes.

Before you check the repository, which two files do you expect to see on its main page?

• Return to the main page of login-wall-site.
• Confirm that the file list contains README.md and index.html.

You should see both files on the default branch. That proves your static site is committed and ready for Vercel to import.

✔️ Awesome, I've got everything!

Your accounts, local tools, private browser window, and repository are ready for deployment.

ⓧ I'd like to double check the full setup

Your GitHub repository login-wall-site is created with a small static site committed to its default branch. It is ready to import into Vercel.

Git is installed and configured. Your terminal has the curl command available.

Your browser can open a private or incognito window for signed-out deployment checks.

Your deployment source is ready. Next up, you will import the repository into Vercel and see the site load from a public production URL.

Deploy Your Public Site

Your small site already lives in a GitHub repository. That gives Vercel a source it can deploy.

The risk starts when that deployment gets a public URL. No access control limits who can reach it.

In this step, you'll connect the repository to a Vercel project. You'll test its production URL from a private window as an unauthenticated visitor.

In this step, get ready to:

• Import the login-wall-site GitHub repository into Vercel.
• Deploy the repository's default branch to a production URL.
• Confirm the production site is public from a private window.

Import the GitHub repository

A Vercel project stores the connection to your repository. That connection lets Vercel turn committed code into live deployments.

• In the browser session that is already signed in to Vercel, go to the Vercel dashboard.
• Select Add New… in the top-right corner.
• Select Project from the menu.
• Use the provider dropdown at the top left to show your GitHub repositories.
• Approve access to login-wall-site if GitHub asks for permission.
• Select the login-wall-site repository from the list.

You'll reach the project configuration page with login-wall-site selected as the source repository.

Repository missing from the list?

• Check that the provider dropdown shows GitHub.
• Confirm that your signed-in GitHub account can access login-wall-site.
• Approve repository access if GitHub displays a permission request.

Still stuck? Help me find my GitHub repository in Vercel. You can also ask the NextWork community.

Deploy the default branch

The configuration page controls how Vercel builds the selected repository. Your static site is already prepared, so the existing build settings can stay in place.

• Confirm Project Name contains login-wall-site.
• Keep the detected Framework Preset.
• Keep the existing build settings for the static site.

The deployment may spend a short while building. A changing build log means the process is still active.

• Select Deploy.

When the deployment finishes, you'll see a Ready status. You'll also see a generated production URL.

Deployment not reaching Ready?

• Review the build output for the first failed file or command.
• Confirm that the repository's default branch still contains the committed static site.
• Retry the deployment after correcting the reported problem.

Need help reading the failure? Help me troubleshoot my failed Vercel deployment..

• Record the generated production URL here: your Vercel production URL.

What did Vercel create?

The Vercel project login-wall-site is now connected to the GitHub repository with the same name. Its default branch provides the production deployment.

Future commits to that production branch can trigger new deployments through the same connection.

Test the public production URL

A private browser window does not carry the signed-in Vercel session from your regular window. It gives you the access context of an unauthenticated visitor.

Before you visit the URL, do you expect Vercel to ask this visitor to sign in?

• Switch back to the private or incognito window from earlier.
• Paste your Vercel production URL into the address bar.
• Press Enter.

You'll see your site load with no Vercel login screen. This proves Deployment Protection is not enabled for production.

Site not loading in the private window?

• Return to the deployment page from earlier.
• Confirm that the deployment status still shows Ready.
• Compare the private-window address with your recorded production URL.

Seeing a login screen can mean you copied a preview URL. Help me verify that I am testing the Vercel production URL..

You have your baseline: an unauthenticated visitor can reach the live site. Next up, you'll place a login wall in front of this production deployment.

Protect Every Deployment

Your production deployment is live. Its public URL still gives every visitor access to your unfinished site.

A public work in progress can be indexed before it is ready. In this step, you'll use Deployment Protection to require Vercel Authentication across every deployment.

In this step, get ready to:

• Locate the Deployment Protection settings for login-wall-site.
• Apply Vercel Authentication to every deployment.
• Verify that an unauthenticated visitor reaches the login screen.

Find the protection settings

Deployment Protection is configured at the project level. The scope you choose controls access to deployments connected to that project.

• Return to the Vercel project dashboard for login-wall-site from earlier.
• Select Settings in the project navigation.
• Select Deployment Protection on the Settings page.

You'll see the Vercel Authentication controls for this project. The current configuration does not protect production.

Why Is Protection Set Per Project?

A project can create production deployments or preview deployments. One project-level protection policy keeps access consistent across those URLs.

Set the protection scope

The All Deployments scope covers the production deployment. It also covers preview deployments connected to this project.

• Select All Deployments in the Vercel Authentication section.
• Select Save.

That's the login wall in place. You'll see All Deployments remain selected after Vercel saves the setting.

What Did This Change?

Vercel now checks whether a visitor can access the project before showing a deployment. Your existing site stays deployed at the same production URL.

Can't Save the Protection Setting?

• Confirm the dashboard header shows login-wall-site.
• Confirm you are signed in with the account that owns the project.
• Select Save again if the setting did not remain selected.

Use this troubleshooting prompt for tailored help. You can also ask the Vercel Community for support.

Test the login wall

A private browser window gives you an unauthenticated check. It shows what someone without project access sees.

• Switch back to the private or incognito window from earlier.

Before you reload, what do you expect an unauthenticated visitor to see now?

• Reload the Vercel-generated production URL.

You'll see the Vercel login screen instead of your site. That result proves the production deployment now requires authentication.

Still Seeing Your Site?

• Confirm the test is running in the private or incognito window from earlier.
• Confirm you are testing the Vercel-generated production URL.
• In Deployment Protection from earlier, confirm All Deployments remains selected.

Use this troubleshooting prompt to trace why the production URL remains public.

Your production URL now blocks unauthenticated visitors. Next, you'll sign in with the project owner account to prove the deployment still works.

Verify the Login Wall

Your production deployment now has Vercel Authentication enabled across all deployments. That setting only becomes trustworthy once you test the visitor experience.

A normal browser session may already know who you are. A private/incognito window gives you the unauthenticated view that a public visitor receives.

In this step, get ready to:

• Return to the production URL in your private/incognito window.
• Reload the protected production deployment while unauthenticated.
• Capture proof that the login screen blocks access to your site.

Return to the private window

The private/incognito window from your earlier test separates this check from your signed-in browser session. Keeping the same production URL makes the protection setting the only meaningful change.

• Switch back to the private/incognito window from your earlier public-access test.
• Check that you have not signed in to Vercel inside this private/incognito window.
• Return to the Vercel-generated production URL from your earlier test.

Reload the protected deployment

Before you reload, consider which page you expect the protected production URL to show.

• Reload the production URL in the private/incognito window.

You should see the Vercel login screen instead of your static site. This proves unauthenticated visitors cannot reach the production deployment.

That is a strong checkpoint. Your production site now stops unauthenticated visitors at the login screen.

Still Seeing Your Site?

• Confirm that the address bar shows the Vercel-generated production URL from earlier.
• Confirm that the active browser window is private/incognito.
• Check whether Vercel Authentication still shows All Deployments on the Deployment Protection page from earlier.

Ask for help diagnosing the protected production URL.

The login wall now works for visitors who are not signed in. Next up, you'll sign in with the account that owns the project to prove authorised access still reaches the site.

Access the Protected Site

Your production URL now stops unauthenticated visitors at the Vercel login screen. That result confirms Vercel Authentication is active for the project.

A login wall should control who reaches the site while the successful deployment stays intact. In this step, you'll sign in as the project owner. You will confirm the same deployment still serves your page.

In this step, get ready to:

• Authenticate through the production login screen as the project owner.
• Load the protected production site from the authenticated private session.
• Confirm the successful deployment remains available to an authorized visitor.

Sign in as the project owner

The login screen has already proved that an anonymous private session is blocked. The next result depends on the account's access to login-wall-site.

The sign-in stays inside this private browser session. Your deployment and protection setting remain unchanged.

• Return to the private window from the previous check.
• Choose the sign-in method connected to the Vercel account that owns login-wall-site.
• Complete any identity check requested by the account provider.
• Wait for the protected production URL to load after sign-in.

You should now see your static site in the private window. You've crossed the login wall as the project owner.

Still seeing the login screen?

• Confirm that the account you used owns the Vercel project login-wall-site.
• Complete any account verification that is still waiting.
• Load the protected production URL again after authentication finishes.

Need another pair of eyes? Help me troubleshoot why the protected Vercel site still shows its login screen after I signed in.

Verify the deployment still loads

The URL and deployment match the ones used for the unauthenticated check. The authenticated browser session is the only changed condition.

Before you reload the page, what do you expect this authenticated session to show?

• Reload the Vercel-generated production URL in the same private window.

You'll see your static site again. The login screen no longer interrupts this authenticated session.

What did this prove?

The production URL showed the login screen before authentication. The same URL serves the static site after the project owner signs in.

Your deployment stayed successful throughout both checks. Vercel Authentication controls who can reach it.

Your production site now admits its owner while stopping unauthenticated visitors. Next up, you'll create a preview deployment and leave only that preview open.

Open a Preview Exception

You have confirmed that Vercel Authentication protects your production site without changing its successful build. Every unauthenticated visitor now meets the login wall.

A reviewer may need one public preview while production remains private. A Deployment Protection Exception opens one preview domain without changing the protection applied to the rest of the project.

In this step, get ready to:

• Publish a share-preview branch to GitHub.
• Confirm that Vercel creates a successful Preview Deployment for the branch.
• Make the generated preview domain publicly accessible through a Deployment Protection Exception.

Publish the preview branch

Vercel creates a Preview Deployment when you push a non-production branch to the connected repository. The new branch can use the current site because this test focuses on access behavior.

• Return to the terminal session you used for login-wall-site.
• Create the preview branch and publish it by running these commands:

git switch -c share-preview
git push -u origin share-preview

What do these commands do?

• The first command creates share-preview from your current commit. It also switches your local repository to that branch.
• The second command sends the branch to the origin remote. The -u option connects your local branch to its remote branch for future pushes.

You should see terminal output confirming that the remote branch was created. Good work. The push now gives Vercel the event it needs to start a Preview Deployment.

Branch push not working?

Confirm that your terminal is working with the login-wall-site repository. A push failure can also mean your Git credentials no longer have access to the connected GitHub repository.

Still stuck? Help me troubleshoot why my share-preview branch will not push to GitHub.

Record the preview domain

Each Preview Deployment receives a generated URL. Its branch-specific URL continues to point at the latest successful deployment from share-preview.

• Switch back to the Vercel dashboard for login-wall-site.
• Select Deployments in the project sidebar.
• Find the deployment associated with share-preview.
• Wait until the deployment shows that it completed successfully.
• Select the successful deployment.
• Copy the branch-specific generated domain from the deployment page.
• Record the generated preview domain here: your Vercel preview domain.

That is your public-sharing candidate. Production still uses its separate protected domain.

Make the preview publicly accessible

A Deployment Protection Exception removes protection from every current deployment served on the selected preview domain. Future deployments on that domain also remain public until you remove the exception.

This setting deliberately opens the chosen domain to anyone. Your production domain remains protected because the exception targets only the preview domain you recorded.

• Return to Settings in the login-wall-site project.
• Select Deployment Protection.
• Scroll to the Deployment Protection Exceptions section.
• Select Add Domain.
• Enter your Vercel preview domain in the Unprotect Domain modal.
• Select Continue.

Check the domain before confirming

This confirmation makes the whole preview domain public. The production domain should not appear in either confirmation field.

• Re-enter your Vercel preview domain in the first confirmation input.
• Enter unprotect my domain in the second confirmation input.
• Select Confirm.

What did the exception change?

The preview domain now bypasses Deployment Protection. The project-level All Deployments setting remains active for every domain without an exception.

Before you test, which screen do you expect from the excepted preview domain? Hold your answer in mind.

• Close every private or incognito window left from the earlier login test.
• Start a fresh private or incognito window from your browser menu.
• Enter https:// followed by your Vercel preview domain in the address bar.
• Press Enter.

You should see your static site immediately without a Vercel login screen. That proves the exception opens the preview while the separate production domain stays protected.

Still seeing the login screen?

• Confirm that the domain listed under Unprotected Domains exactly matches the preview domain in your browser.
• Confirm that you added the branch-specific preview domain instead of the production domain.
• Start another fresh private session after closing every existing private or incognito window.

Need another pair of eyes? Help me find why my Vercel preview exception still shows the login screen.

Your preview is now public while production keeps its login wall. Next, you will prove that difference from the terminal by comparing both responses.

Compare Access with Curl

You proved that Vercel Authentication blocks anonymous visitors on production. You also proved that the excepted preview stays public.

The browser showed the user experience. Now curl lets you inspect the HTTP response behind that difference.

In this step, get ready to:

• Send an unauthenticated curl request to the protected production URL.
• Send an unauthenticated curl request to the excepted preview URL.
• Compare the two responses from the terminal.

Test the protected production URL

A curl request does not carry your browser's signed-in session. This gives you an unauthenticated view of the production deployment.

• Copy the production deployment URL from the private browser address bar into https://your-production-domain.vercel.app.
• Return to the terminal from earlier.

Before you run this, predict whether the request reaches your site or the login wall.

• Request the production URL with response headers included by running this command:

curl -i [[PRODUCTION_URL="https://your-production-domain.vercel.app"]]

What does this command show?

• The curl command sends a request without browser cookies.
• The -i option includes response headers before the response body.

You should see an authentication response such as HTTP 401. The following headers point to protection or login handling.

Your site's page content is unavailable to this anonymous request.

Production response not protected?

• Check that the copied address belongs to the production deployment.
• Confirm that Vercel Authentication still shows All Deployments.

Still seeing your site content? Help me troubleshoot the production curl response.

Test the excepted preview URL

The preview domain has a Deployment Protection Exception. An anonymous request to that exact domain should reach your site.

• Copy the preview deployment URL from the private browser address bar into https://your-preview-domain.vercel.app.
• Return to the terminal from earlier.

Before you run this, predict whether the preview returns an authentication response or your site's content.

• Request the preview URL with response headers included by running this command:

curl -i [[PREVIEW_URL="https://your-preview-domain.vercel.app"]]

What does this command show?

• The request reaches the preview domain without a browser login session.
• The -i option places the response headers above your site's content.

Your output should begin with HTTP 200. After the headers, you'll see your site's page content.

That successful response proves the exception applies to this preview domain.

Preview response still protected?

• Check that the copied address belongs to the preview deployment for the share-preview branch.
• Confirm that the Deployment Protection Exception uses this exact preview domain.

Still getting an authentication response? Help me troubleshoot the preview exception.

Compare the two responses

The status line gives each request's outcome. The response body shows what an anonymous client receives.

Before you compare the outputs, predict which response contains your site's page content.

• Find the first HTTP status line in the production response.
• Find the first HTTP status line in the preview response.
• Review the production headers for protection or login clues.
• Confirm that the preview body includes your site's content.

The protected production response should show an authentication result such as HTTP 401. Its headers indicate protection or login handling.

The excepted preview response should show HTTP 200. Its body includes your site's content.

That's the final proof. Your login wall protects production while the exception keeps this preview public.

Secret mission

Run an Access Revocation Drill

A public preview should stay open only while a reviewer needs it. Temporarily remove the existing exception to prove the login wall returns. Restore approved sharing without changing the deployment.

Clean Up Your Resources

Clean Up Your Resources

The access controls you configured add no extra cost on any Vercel plan. Choose the cleanup option that matches what you want to do next.

Resources you used:

• The Vercel Authentication configuration set to All Deployments for the login-wall-site project.
• The Deployment Protection Exception that gives the share-preview preview domain public access.

Keep everything running

No action is needed. Choose this if the production site is unfinished or the public preview still needs to be shared.

• Keep Vercel Authentication set to All Deployments so the production URL continues to require a login.
• Keep the Deployment Protection Exception while people still need unauthenticated access to the share-preview preview.
• Remove the exception when the preview no longer needs to be public.

Your production URL remains protected. The excepted preview URL remains publicly accessible.

Pause - I'll come back to this later

Remove public access from the preview while keeping the login wall active. Your project stays connected to its repository for when you return.

• Select the login-wall-site project in Vercel.
• Select Settings.
• Select Deployment Protection.
• Locate the Deployment Protection Exception for the share-preview preview domain.
• Use the deletion control beside that exception.
• Leave Vercel Authentication set to All Deployments.
• Reload the preview URL in a private or incognito window.

You will see the Vercel login screen instead of the site. This confirms that the preview exception is gone.

Delete - I don't want to use this again

Remove the access configuration added during this project. This restores public production access while protecting preview deployments.

Production Becomes Public

Changing the protection scope exposes the production site to unauthenticated visitors. Pause here if the site is still unfinished.

• Select the login-wall-site project in Vercel.
• Select Settings.
• Select Deployment Protection.
• Locate the Deployment Protection Exception for the share-preview preview domain.
• Use the deletion control beside that exception.
• Find the Vercel Authentication setting.
• Change All Deployments to the option that applies protection to preview deployments only.
• Save the updated protection setting.

The exception is now removed. The login wall now applies only to preview deployments.

• Reload the production URL in a private or incognito window.
• Reload the preview URL in the same private or incognito window.

You will see the production site load without a login. You will see the Vercel login screen when you visit the preview URL.

Nice Work!

Nice Work!

You did it! Your live site now keeps production behind a login wall while its excepted preview stays publicly accessible.

You've learned how to:

• Deployed a static site from a GitHub repository to Vercel. Confirmed that anyone could initially open the production URL in a private browser window.
• Protected production access with Vercel Authentication. Proved that authorized visitors could still reach the working site after signing in.
• Created a public preview exception for the share-preview branch. Used curl to compare the production and preview responses through their status codes and headers.
• Secret Mission: Completed an optional challenge to push your deployment protection skills further.

Ready to quiz yourself?