Use Vercel CLI

The card improvement is saved locally. To review it on a deployed URL before publishing, we need to connect this folder to the Vercel project that already hosts our site. We'll check that connection before sending any files.

Open a shell terminal in the website folder and check the current state:

pwd
git status
git remote get-url origin

The repository should be the same one connected in 2.5. Leave fx before entering these shell commands, or use a separate terminal.

Outcome

Install Vercel CLI, sign in, and link the local website folder to its existing Vercel project.

Hands-on exercise 3.3

Install the command-line tool

A CLI is a command-line interface. Vercel CLI lets us manage deployments from the terminal. We have already used the Vercel dashboard in a browser; the CLI provides another way to work with those projects.

This course's command reference uses Vercel CLI 57.0.0. Install that version with npm, including when the application's own package manager is pnpm:

npm install --global vercel@57.0.0
vercel --version

The global install makes vercel available as a command. It doesn't add the CLI to our website's dependencies. The version check should report 57.0.0; use Vercel's CLI documentation when troubleshooting installation.

If the install reports a permission error, check the Node installation from 2.3 before adding administrative privileges. A version-manager installation keeps global packages in its managed location. Follow that installer's guidance rather than changing permissions across system folders.

Confirm the account

Sign in using the same Vercel account that can access the existing project:

vercel login
vercel whoami

Complete the browser flow and return to the terminal. whoami reports the authenticated user. Signing into v0 alone doesn't prove that this CLI account has permission to deploy the associated Vercel project.

Open the project in the Vercel dashboard. Note its project name and the account or team containing it, called its scope. Two teams can have similarly named projects, so check the scope as well as the name.

If the project belongs to a work team with a restricted role, use the team's access process or your own authorized course project. Keep the existing access rules. This lesson doesn't require a new paid project or a change to a colleague's permissions.

Link the folder

Return to the project root, where package.json lives, and run:

vercel link

Read each prompt. Select the scope containing the existing site, then choose to link to an existing project and select that project. If the intended project is missing, cancel with Ctrl+C and investigate the account or scope before continuing.

The link command records the association locally. Linking doesn't deploy the heading or card changes. We will run the deployment command explicitly in 3.4.

After linking, look for .vercel in the editor. A dot at the beginning makes a folder hidden in some file browsers. Its local metadata identifies the linked organization and project. We don't need to edit that metadata by hand.

Keep local metadata out of the repository

Open .gitignore in the editor. This file tells Git which untracked files to leave out of normal staging. Ensure it includes .vercel/ and .env* on separate lines. The reference already has both rules.

Check the rules from the shell:

git check-ignore .vercel/project.json
git ls-files .vercel
git status

The first command should print .vercel/project.json, indicating it is ignored. git ls-files .vercel should print nothing. An ignore rule doesn't remove a file already committed; investigate a tracked metadata file before continuing.

We'll use the environment-file rule when adding email credentials. For now, don't download or edit environment variables. The catalog preview needs no email configuration.

Try It

Compare the project name in the CLI link result with the dashboard and the Git repository from 2.5. Confirm the production URL still shows the previously released website. No deployment should have been created by vercel link alone.

Run vercel whoami once more if you changed accounts during setup. Keep the correct project tab open; we will use it to compare the preview and production deployments.

The intended project doesn't appear

Check both the signed-in user and selected scope. Confirm that the dashboard user has access to the same project. Cancel the link flow while resolving access; creating another project with a similar name would give us a different deployment destination.

The wrong project was selected

Run vercel link again from this folder and choose the correct existing project. Review the new association before deploying. There's no need to delete either remote project to correct a local link.

Commit

If .gitignore already had the required rules, this lesson needs no commit. If we added them, inspect the file and save that specific change:

git add .gitignore
git diff --cached
git commit -m "chore(repo): ignore local Vercel metadata and secrets"

Keep it local with the card edit. We will review a preview before pushing either commit.

Done-When

• The CLI version check succeeds.
• The authenticated user can access the intended scope and project.
• This folder is linked to that existing project.
• Local Vercel metadata is ignored, and linking has not created a deployment.

Solution

With the CLI installed, the connection sequence is:

vercel login
vercel whoami
vercel link
git check-ignore .vercel/project.json
git status

Choose the existing project during linking and inspect any .gitignore change afterward. This folder should now point to the Vercel project that hosts our published site.