How to deploy a GitHub website to Vercel

Before you start

You need the site’s code in a GitHub repository you control, and a Vercel account of your own. If the repository isn’t yours yet, the guide to putting your website’s code in GitHub comes first. If you’re moving from another host, keep it running: nothing here touches the domain until the end.

One plan note. Vercel’s free Hobby plan is for personal, non-commercial use and can’t deploy from a private repository that belongs to a GitHub organization. A business site wants a Pro team, which is also what lets you add other people without sharing your login.

Step 1: Know what kind of site it is

You don’t need to know the framework by name, because Vercel detects it during import. It helps to know whether the site is static (a folder of files) or has a server (sign-in, forms that save, a database), because that decides what to test in step 5. Two quick looks at the repository on GitHub tell you most of it:

• package.json lists the framework under dependencies: next, vite, astro, @tanstack/react-start and so on. Vercel reads this file to pick its Framework Preset.
• A folder such as api, server or app/api, or a file called .env.example, means there are environment variables to recreate. The secrets guide explains how to list them.

Step 2: Import the repository

1. In the Vercel dashboard, choose Add New, then Project.
2. Under Import Git Repository, connect GitHub if you haven’t. Vercel installs its GitHub App on your account or organization; when it asks which repositories, choose only the ones Vercel should see rather than all of them. You can add more later.
3. Find the repository and click Import.
4. On the configuration screen, check the Framework Preset Vercel detected. If it says something plausible, leave it. If it says “Other” for a site you know is Next.js or Vite, pick the right one from the list.

Step 3: Root directory and build settings

Most sites need nothing here. Two cases do:

• The repository contains more than one app, for example a web folder and an api folder, or apps/site. Set Root Directory to the folder that holds the website’s package.json. Vercel then treats that folder as the project.
• The detected settings are wrong. Build and Output Settings can be overridden: the build command, the output directory and the install command. Only change these on the advice of the framework’s Vercel documentation, a developer, or your coding agent. A wrong override is the most common reason a first deploy fails.
• The build wants a particular Node.js version. New projects use the latest long-term-support version Vercel offers. If the build log complains, the version is set on the project’s Build and Deployment settings page, and a developer can pin it in package.json instead.

If the first build fails, read the error in the deployment log before changing anything. Vercel’s framework documentation lists the correct settings for each framework, and a failed build costs nothing while the domain still points at the old host.

Step 4: Environment variables

Still on the configuration screen, or later under the project’s Settings, then Environment Variables, enter every variable the site needs. Vercel keeps separate values for Production, Preview and Development; put the live values in Production. For secrets, turn on the sensitive option so the value can’t be read back from the dashboard afterwards. Values that were shown once at the issuing service and can’t be read from the old host have to be regenerated there; the secrets guide covers which ones.

Step 5: Deploy and test on the vercel.app address

Click Deploy. Vercel builds the site and gives it a .vercel.app address for production, made from the project name and your team’s name, that keeps pointing at whatever is currently in production. Open it and test the site as a visitor would:

Fix problems here. Nobody is looking yet. Every push to the repository from now on creates a new deployment, and pushes to any branch other than the production branch create preview deployments with their own addresses, which is how you’ll test changes later.

Step 6: Add the domain

In the project, open Settings, then Domains, and add the bare domain. Vercel suggests adding the www version too; accept, and choose which is primary. Vercel then shows the exact records to add at your DNS provider:

• For the bare domain, an A record. The general-purpose value is 76.76.21.21, but use whatever the domain card shows.
• For www, a CNAME to a per-project name ending in .vercel-dns-0NN.com, shown on the card.
• A TXT record, shown on the card, only if Vercel asks for one, which happens when the domain is in use by another Vercel account. Vercel doesn’t use IPv6, so there’s no AAAA record to add.

Add those records at your existing DNS provider by editing the current website records, and remove any outdated record for the same name; Vercel’s troubleshooting page says leftover records are a common cause of its “Invalid Configuration” alert. Don’t change nameservers to Vercel’s unless you’ve decided to move DNS on purpose; Vercel’s own docs say changing only the A or CNAME record doesn’t require moving the rest, and that adding a domain to a project doesn’t by itself change your email configuration. The guide to connecting a domain without breaking email covers capturing your records first, lowering TTLs, and the conflicts a domain screen can throw up.

Step 7: HTTPS

Once the records resolve, the domain card turns valid and Vercel requests a certificate from Let’s Encrypt automatically. It only succeeds after the DNS records are in place and visible, so allow for caching. If it stays pending, check for a CAA record in your DNS; if one exists it must allow Let’s Encrypt, and Vercel documents the exact record to add. Then verify the bare domain and www both load over https, and run the email checks in the domain guide.

Later: pushes, rollbacks and leaving

• Every push to the production branch (usually main) deploys to the domain. Pushes to other branches get preview addresses.
• If a push doesn’t show up on the site, the guide to a website not updating after a deploy traces the change from the edit to the browser; for domain and certificate problems after step 6, see website not showing after a DNS change and HTTPS not working.
• Rolling back: Instant Rollback in the project’s Deployments view puts a previous production deployment back on the domain. On Hobby it reaches only the immediately previous one; after a rollback Vercel stops auto-assigning new deployments to the domain until you undo it. Redeploy rebuilds the current commit, useful after changing a variable.
• Adding people: invite them to the team with a role rather than sharing your login. The access guide covers roles.
• Leaving: move the site to another host with the host move guide, change the two DNS records, then remove the domain from the project, disconnect the Git repository under Settings, then Git, and delete the project. Environment variables live on the project, so record them before deleting.

Checklist

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

• Deploying Git repositories with Vercel · Vercel
• Managing projects · Vercel
• Configuring a build · Vercel
• Node.js versions · Vercel
• Generated URLs · Vercel
• Managing deployments · Vercel
• Domains troubleshooting · Vercel
• Managing DNS records · Vercel
• Removing a domain · Vercel
• Environment variables · Vercel
• Sensitive environment variables · Vercel
• Adding a custom domain · Vercel
• A record and CAA with Vercel · Vercel
• Working with SSL · Vercel
• Deploying and redirecting domains · Vercel
• Instant Rollback · Vercel
• Git settings · Vercel
• Hobby plan · Vercel
• Fair use guidelines · Vercel