Module 4, Lesson 3: Connect to Vercel

11 min read min

Before We Start

Here’s what I’d expect you to have in place before this lesson:

From previous lessons:

Your landing page (index.html) is complete and working locally — Module 4, Lesson 1
The Kit integration is live and tested — Module 4, Lesson 2
You’re comfortable with WebStorm’s terminal — Module 3, Lesson 1

Tools / setup you’ll need:

WebStorm (or VS Code)
A GitHub account — if you don’t have one yet, go to github.com and sign up before starting this lesson
A Vercel account — we’ll create this during the lesson using GitHub login, so you don’t need to pre-register

By the end of this lesson, you’ll:

Have your project pushed to a GitHub repository
Have Vercel connected to that GitHub repo and your page deployed
Have a live, public URL that anyone on the internet can visit

About This Lesson

Duration: ~8 minutes video + ~15 minutes practice Skill Level: Intermediate What You’ll Build: A publicly live deployment of your landing page via GitHub and Vercel

This is the moment it all becomes real. Up until now, everything we’ve been building has been running on your machine — nobody else can see it. In this lesson we push it to GitHub, connect it to Vercel, and get a live URL on the internet. It takes less time than you’d think.

Watch the Lesson

ℹ️

How I’d suggest going through this: Watch the video first without stopping — just get the big picture. Then come back here and work through the guide section by section, pausing the video at the timestamps I’ve noted. After that, this guide is your reference — you shouldn’t need to rewatch to look something up.

What We’re Covering

Here’s what I’m walking you through in this lesson and why it matters:

Creating a GitHub repository — where your project lives so Vercel can access it
Pushing your local project to GitHub — getting all your files off your machine and into the repo
Signing up for Vercel and connecting GitHub — one-click deployment setup
Deploying your site — going from a GitHub repo to a live public URL
What comes next — a teaser on what the Vercel URL looks like and why we’ll add a proper domain in the next lesson

1. Let’s Set the Scene (~0:00)

In the previous session, we connected our page to Kit — where we track and capture user emails. The landing page looks right, the CTA works, emails go into Kit when someone signs up. That’s all good.

Now we want to make the website publicly available to everyone. Right now it only runs on localhost — your machine. We need it on the actual internet.

To do that, we need two things: a place to store the code (GitHub), and a service that reads that code and hosts it as a website (Vercel). Both are free. Both take about five minutes to set up. Let’s do it.

2. The Core Idea

2.1 GitHub: Where Your Code Lives

GitHub is where we store the project. Think of it as a cloud backup for your code — but more than that, it’s how Vercel knows what to deploy. Every time you push changes to GitHub, Vercel can pick them up automatically and redeploy your site. That’s the deployment loop we’re setting up here.

If you followed along in Module 1 or have done any git work before, you’ll already have a GitHub account. If not — go to github.com and sign up before you continue.

2.2 Vercel: Where Your Site Lives

Vercel is a hosting platform. You point it at your GitHub repo, tell it which folder to deploy, and it makes your files available on a public URL. It handles all the infrastructure — the servers, the CDN, the HTTPS certificate — so you don’t have to.

The free tier is genuinely generous. You can host multiple projects, get automatic deploys on every push, and the performance is solid. For a landing page at this stage, you don’t need anything else.

2.3 Why This Order Matters

We’re pushing to GitHub first because Vercel connects to GitHub — not directly to your machine. Once the repo is there, Vercel can read it, deploy it, and watch for any future changes. That’s why git comes before Vercel, not the other way around.

3. Step 1 — Push Your Project to GitHub (~0:20)

3.1 Create a New Repository

Go to github.com and log in. At the top of the page, click the + button and select New repository.

Here’s how I fill this out:

Repository name: Give it the same name as your project folder in WebStorm. Mine is nurturo-landing-page. Matching names keeps things clear.
Description: Optional. I put something short like “Nurturo landing page” — it’s just for your own reference.
Visibility: Set this to Private for now. Private means only you can see it. Public means anyone on GitHub can browse your code. You can always make it public later — but while you’re building, keep it private.
Initialise with a README: Leave the defaults as-is. Don’t check this box — you already have files locally and we don’t want GitHub adding anything that’ll conflict.

Click Create repository.

3.2 Connect Your Local Project to GitHub

Once the repo is created, GitHub shows you two options for what to do next. You want the first block — the one that says “create a new repository on the command line.” There’s a copy button in the top right of that block. Copy all of it.

Now open WebStorm. If the terminal isn’t open, press Alt+F12 (or Command+E on Mac and type “terminal”). Create a new terminal tab so you’re starting fresh — click the + icon in the terminal panel.

Paste the command block you copied from GitHub and hit enter.

⚠️

Authentication errors on push?
If you get an error that says something like “authentication failed” or “password not supported,” try this: in GitHub, copy the SSH version of the command instead of the HTTPS version (there’s a tab toggle at the top of the command block). If that still fails, run rm -rf .git in your terminal to clear any broken git state, then paste the command again from scratch. That usually sorts it out.

3.3 Verify the Files Are There

After the command runs, go back to GitHub and refresh the page for your new repository. You should now see your files — index.html, README.md, and everything else in the project.

The critical one to check is index.html. If it’s there, you’re good to move on. If it’s not there — only README.md is showing up — read the next section.

3.4 If Your Files Didn’t Push

This happened to me during recording, so I’ll walk you through the fix.

Sometimes the initial git command pushes the remote setup but doesn’t actually include all your local files. If you look at the GitHub repo and see only the README, here’s what to do:

In WebStorm, press Command+K (Mac) or Ctrl+K (Windows) to open the Commit dialog. Scroll down and you’ll see a section that says something like “Unversioned files.” Check that box — this tells git to include everything that isn’t tracked yet. In the commit message field, type something like Adding all files. Then click the dropdown arrow next to Commit and choose Commit and Push.

WebStorm will warn you about things — just acknowledge them and push anyway. Go back to GitHub, refresh, and now all your files should be there.

💡

The WebStorm commit dialog is actually one of the nicer ways to do this — it gives you a visual of exactly what’s getting committed and what’s being left out. Once you get the hang of it, you’ll probably prefer it over typing git commands manually.

4. Step 2 — Deploy with Vercel (~5:40)

Open a new browser tab and go to vercel.com. Click Start Deploying.

Vercel will ask you to sign in. Choose Continue with GitHub — this is the fastest path and it means Vercel can access your repos directly without any extra configuration. Click Authorize when GitHub asks for permission.

Vercel will pull in your account almost immediately.

4.2 Import Your Project

Once you’re in the Vercel dashboard, it should show you your GitHub repositories. Find the one you just created. If you only have one repo, it’ll probably already be highlighted.

Click Import.

Vercel will try to detect what kind of project it is. For a simple HTML/CSS page, there’s nothing to configure. Leave all the defaults as-is. Don’t change the project name, don’t touch the build settings.

Click Deploy.

4.3 Watch It Deploy

Vercel will say “deployment starting” and then it’ll finish — usually in under a minute. When it’s done, click Continue to Dashboard.

You’ll see a preview of your page right there in the dashboard. Click Visit to open it in the browser.

That’s it. Your page is live.

5. You’re Live — Here’s What That Means (~7:00)

When you open that URL in the browser, notice it: it should be something like your-project-name.vercel.app. That URL is public. Anyone anywhere in the world can type it in and see your page. It’s not on localhost anymore.

This is real.

That said — yourproject.vercel.app doesn’t look like a proper website domain. Most things you visit on the internet have something clean like google.com or yourproduct.co. The reason we’re getting the Vercel subdomain for now is because Vercel gives it to us for free. It’s a hosted URL, just with their domain on it.

In the next lesson, we’re going to fix that. We’ll buy a proper domain name and attach it to this Vercel deployment so your page has a real, professional address. But the site being live right now — that part is done.

✅

If you’ve got a working URL on vercel.app and the page loads — you’re done with this lesson. The foundation is in place. Next up: a proper domain.

6. Try It Yourself

Exercise 1: Get It Live

What to do: Follow sections 3 and 4. Create the GitHub repo, push your files, connect Vercel, and get to the point where you have a live vercel.app URL.

A nudge if you’re stuck: If your files aren’t showing up on GitHub after the first push, go to the Commit dialog in WebStorm (Command+K / Ctrl+K), check the “Unversioned files” box, and do a Commit and Push. That’ll catch anything git missed.

How you’ll know it’s working: You’ll have a URL ending in .vercel.app that loads your landing page in the browser — not just a local preview, but a real link you can share with anyone.

What to do: Once your page is live, copy the Vercel URL and send it to someone — a friend, a family member, anyone. Ask them to confirm they can see it.

What this is practising: End-to-end verification. “It works on my machine” is not the same as “it works.” Confirming someone else can load it closes that loop.

7. You Should Be Able to Build This Now

Here’s what you can do with what we just covered:

Push any local project to a GitHub repo using WebStorm’s terminal
Connect a GitHub repo to Vercel and deploy a live website in under five minutes
Understand the GitHub → Vercel pipeline and how automatic deploys work

Check Yourself

I have a GitHub account and my project is in a private repository
All my project files (including index.html) are visible in the GitHub repo
My site is deployed on Vercel and I have a live .vercel.app URL
I’ve opened that URL in the browser and confirmed the page loads correctly

✅

Tick those boxes and you’re ready for Module 4, Lesson 4 — where we attach a proper custom domain to this deployment.

If Something’s Not Working

⚠️

Authentication failed when pushing to GitHub
What’s happening: GitHub no longer accepts plain passwords over HTTPS. You need either SSH authentication or a personal access token.
How to fix it: Switch to the SSH version of the push command (toggle the SSH tab on the GitHub repo page), or set up a GitHub personal access token and use that as your password. If neither option works for you, drop a question in Discord.

⚠️

Only README showing on GitHub, not index.html
What’s happening: Git initialised but didn’t stage your existing files for commit — only the README was tracked.
How to fix it: In WebStorm, open the Commit dialog (Command+K / Ctrl+K), scroll to “Unversioned files,” check that box, write a commit message, and choose Commit and Push.

⚠️

Vercel deployment failed
What’s happening: Usually a configuration issue — Vercel is trying to run a build command that doesn’t apply to a plain HTML file.
How to fix it: Go to your project settings in Vercel → Build & Output Settings → clear out any build command that was auto-detected. For a plain HTML project, there’s nothing to build. Leave everything blank and redeploy.

⚠️

Can’t find my repo in Vercel during import
What’s happening: Vercel may not have permission to see all your GitHub repos — only the ones you’ve granted access to.
How to fix it: In Vercel during import, look for an option like “Adjust GitHub App Permissions” or “Configure GitHub App.” Click that and grant Vercel access to the specific repo you created.

The Short Version

Here’s what I want you to walk away with:

GitHub stores your code — it’s the source of truth that Vercel reads from
Vercel hosts your site — connect it to GitHub, click deploy, done
The pipeline is now live — every time you push changes to GitHub, Vercel can redeploy automatically
The .vercel.app URL is real and public — anyone can visit it, but the domain name needs work — that’s Module 4, Lesson 4

Quick Reference

Terminal Command to Open in WebStorm

Alt+F12   ← open terminal (Windows/Linux)
Command+E → type "terminal"   ← open terminal (Mac)

WebStorm Commit Shortcut

Command+K (Mac) / Ctrl+K (Windows)   ← open Commit dialog

Fix: Clear Broken Git State

rm -rf .git

Run this in your project folder if you hit authentication errors and want to start the git setup fresh. Then paste the GitHub command block again.

Deployment Pipeline

Your machine → WebStorm terminal (git push) → GitHub repo → Vercel → Live URL

Resources

Links & Docs

GitHub — sign up here if you don’t have an account
Vercel — free hosting with GitHub integration
GitHub SSH Setup Guide — if you want to use SSH authentication instead of HTTPS

Tools Used

GitHub — version control and code hosting
Vercel — deployment and hosting platform
WebStorm — IDE used throughout the course (VS Code works fine too)

Questions I Get Asked

Q: Why GitHub? Can I use GitLab or Bitbucket?

Vercel supports all three — GitHub, GitLab, and Bitbucket. I use GitHub because it’s what I know and it’s where the starter repo lives. If you’re already set up with one of the others, Vercel will still connect fine.

Q: Do I have to make the repo public for Vercel to work?

No. Vercel works with private repos — it connects via GitHub’s app permissions, not public access. Keep it private if you want; deployment will still work.

Q: The Vercel URL looks weird. Do I need to fix it?

Not yet. The something.vercel.app URL is a free subdomain that Vercel gives every project. It’s real and it works — it’s just not your final domain. We fix that in the next lesson by adding a custom domain name.

Q: What happens when I update my landing page? Do I have to do this all again?

No — once the GitHub → Vercel connection is set up, every push to GitHub triggers an automatic redeploy. So your workflow going forward is: make changes in WebStorm → commit and push → Vercel picks it up and redeploys automatically. You don’t need to go back into Vercel unless something breaks.

Q: How do I know I’m ready for the next lesson?

You need a working vercel.app URL that loads your page. That’s the only requirement for Module 4, Lesson 4. Don’t move on until that link works.

💬 Stuck? Come Talk to Us

💡

If something’s not clicking or you want to share what you’ve built — come find us in Discord.
The Product Path community → https://discord.gg/RFXRf9yg
Drop your question in the right channel. The community’s active and I check in there too.

Glossary

GitHub: A cloud-based platform for hosting git repositories. Where your project code lives so Vercel (and you) can access it from anywhere. (referenced throughout Module 1 as a prerequisite; first used actively in this lesson — Module 4, Lesson 3)

Repository (repo): A project’s home on GitHub. Contains all the files, commit history, and version tracking for your project. (first actively used in Module 4, Lesson 3)

Vercel: A hosting and deployment platform that connects to your GitHub repo and makes your website publicly available on the internet. Free tier is sufficient for a landing page at this stage. (introduced in Module 4, Lesson 3)

Deployment: The process of taking your code and making it live on the internet. In our setup: push to GitHub → Vercel picks it up → your site updates. (introduced in Module 4, Lesson 3)

localhost: The address your computer uses to serve a website only to itself — nobody else can access it. http://localhost:3000 (or similar) means “running on my machine only.” Getting off localhost is what this lesson is about. (implicitly referenced throughout Module 4; explicitly addressed in Module 4, Lesson 3)

SSH (Secure Shell): An authentication method for connecting to services like GitHub. More secure and convenient than username/password once it’s set up — you don’t need to re-enter credentials every time you push. (mentioned as an alternative authentication method in Module 4, Lesson 3)

git push: The terminal command that sends your locally committed changes up to your GitHub repo. Once it’s there, Vercel can deploy it. (first used in Module 4, Lesson 3)

Commit: A snapshot of your project at a specific point in time, saved in git. Before you can push to GitHub, you commit your changes locally. (first used actively in Module 4, Lesson 3)

Discuss this lesson in the community

Module 4, Lesson 2: Connect to ConvertKit Module 4, Lesson 4: Custom Domain to Vercel