You described your idea to an AI, it wrote the code, and the app works. Except it only works on your computer, at an address nobody else can open: localhost:3000. As long as you stay there, you can't show your work, you can't sell it, and you can't even test it from your phone.
Deploying is the step that turns that folder sitting on your hard drive into a site anyone can open in any browser. With Vercel, that step takes about twenty minutes the first time, and less than two minutes every time after that. No server to rent, no network configuration, no credit card for a personal project.
Here you'll see the minimum prep work (5 minutes), the three ways to deploy depending on your comfort level, a minute-by-minute walkthrough, how to handle your API keys without exposing them to the entire world, and the five mistakes that block most first deployments.
What is Vercel, and why does everyone use it for vibe coding?
Vercel is a host that puts your application online straight from your code, without you having to configure a single server. You hand it your project, it installs it, builds it, then assigns it a secure public address like my-app.vercel.app.
Vibe coding means describing in plain English what you want and letting an assistant like Claude Code write the code for you. In the vast majority of cases, these assistants produce a Next.js or React project. And Next.js is built by Vercel: same company. So compatibility is total, and that's why almost every vibe coding project lands there rather than somewhere else.
What Vercel takes off your hands:
- renting and administering a server
- installing Node.js and dependencies on that server
- the HTTPS certificate (the padlock in the address bar), generated automatically
- manual redeploys: simply pushing your code is enough to update the site
- scaling up if 500 people show up at the same time
The Hobby plan is free for personal, non-commercial projects, with a free .vercel.app subdomain included. The exact quotas and the line between personal and commercial use are spelled out in the official Vercel documentation. As soon as your app starts generating revenue, you need to move to a paid plan: that's the rule, and it's better to know it before you launch a store.
What you need before clicking Deploy (5 minutes)
Three things are enough: a GitHub account, a Vercel account, and a project that starts without errors on your computer.
- A free GitHub account. GitHub is where your code will live online. It's also what lets Vercel detect your changes and republish your app on its own.
- A Vercel account. You create it by signing in with your GitHub account, in thirty seconds, no credit card for the free plan.
- A project that runs locally. If the command npm run dev opens your app in the browser, your foundation is solid.
Then, two checks that prevent the vast majority of failures.
Check 1: the .gitignore file. This file lists everything that must never end up on GitHub. At a minimum it should contain the lines .env, .env.local and node_modules. If your AI assistant didn't create it, ask it to do so before you push any code.
Check 2: the npm run build command passes without errors. That's exactly the command Vercel will run on its machines. If it fails on your machine, it will fail on theirs. If it shows errors, copy the full message and paste it to your assistant, ask it to fix things, then run it again. Two or three rounds are usually enough.
If you're still getting to know the tool, the complete Claude Code tutorial for beginners and the 20 Claude Code commands worth knowing will save you a lot of time during this cleanup phase.
The three ways to deploy your app on Vercel
Three paths lead to the same result: a guided course, importing from GitHub, or the command line. They all give you a public URL; what really sets them apart is what you do when something gets stuck.
Method 1: get guided from start to finish
The hard part of a first deployment is almost never technical. It's that you don't know what you don't know: which folder to push, why the build breaks, where to put a key, what a branch is for. A structured course fills in those gaps.
The Claude Code program for building and publishing your app walks through the whole path, from the initial idea to the app being live, with real error cases shown on screen rather than a perfect project that works on the first try. The built-in AI Lab gives you access to the real tools with credits included, which saves you from stacking three or four subscriptions before you've even published anything.
Worth noting if you want funding to help build your skills: Skilzy offers two state-registered certifications, including the RS7439 certification in AI-assisted content marketing, which you can look up in the France Compétences directory.
Method 2: importing from GitHub
This is the most widely used route, and it's free. You push your code to a GitHub repository, click Add New Project in Vercel, select the repository, and confirm. Vercel recognizes the project type on its own and fills in the settings. Big advantage: every time you push a change, your site updates by itself in one to two minutes.
Method 3: the Vercel command line
If your terminal is already open, you install the tool with npm install -g vercel, sign in with vercel login, run vercel inside the project folder for a preview version, then vercel --prod for the final public version. It's the fastest method once you're used to it, but you lose automatic updates unless you connect GitHub behind it.
| Method | Time the first time | Requirements | Who it's for |
|---|---|---|---|
| 1. Guided course | 20 min, no dead ends | A Skilzy account | Complete beginners who want to reach the finish line |
| 2. GitHub import | 20 to 30 min | GitHub account | Everyone, it's the standard |
| 3. Command line | 10 min | Terminal, Node.js installed | People already comfortable with it |
The deployment, minute by minute
Budget roughly twenty minutes split into six steps, half of which you spend waiting for machines to do their work.
Minutes 0 to 6: push the code to GitHub. Create an empty repository on GitHub, private if you prefer (Vercel can still access it). Then ask your assistant to prepare the push: it will run the commands to initialize, add the files, make the first commit, and link to the repository. Afterwards, check on GitHub that the .env file doesn't appear anywhere in the list. If it's there, stop everything and fix it before you continue.
Minutes 6 to 9: create the project in Vercel. Sign in with GitHub, click Add New then Project, grant access to the repository, and select it.
Minutes 9 to 12: check the settings. Vercel shows a Framework Preset (Next.js, Vite, Astro depending on your project), a Root Directory, and a Build Command. In 9 cases out of 10, you don't touch anything. The one setting to watch is Root Directory: if your code lives in a subfolder like app or frontend, say so here, otherwise the build won't find anything.
Minutes 12 to 16: add the environment variables. Open the Environment Variables section and copy over each line from your local .env file: name on the left, value on the right. This is the most frequently forgotten step, and the one that causes the most blank pages after deployment.
Minutes 16 to 18: start the build. Click Deploy. The log scrolls by live. You see the dependencies install, the build run, then the result. A failure at this stage is normal and it's readable: the exact error message is shown in red in the log.
Minutes 18 to 20: test it for real. Open the URL you're given, then open it again on your phone over cellular, off your home network. Click every button, submit a form, try an action that calls an AI. That's when missing variables reveal themselves.
Your API keys must never end up on GitHub
An API key published in a public repository can be found and used by anyone within minutes, and you're the one who gets the bill. Bots scan GitHub around the clock looking for exactly those strings of characters.
The three rules to remember:
- Keys live in the .env.local file on your computer, and that file is listed in .gitignore. So it never goes online.
- On Vercel, keys go in Environment Variables, never in the code. You can set different values for production and for preview versions.
- The NEXT_PUBLIC_ prefix changes everything. A variable named NEXT_PUBLIC_SOMETHING is sent to the visitor's browser, so everyone can see it. An API key must never carry that prefix. Save it for things that are genuinely public, like a site URL.
If a key has already been pushed to GitHub, deleting the file isn't enough: the history keeps it. You have to revoke the key with the provider and generate a new one. It takes ten seconds and it saves you from a very nasty surprise.
One last point that's often misunderstood: calls to an AI must go out from the server, not from the browser. In practice, your app calls an internal route, and that route is what contacts the API with the key. The principle is laid out in our article on building a company chatbot with Claude, where the same logic applies.
The five mistakes that sink a first deployment
Almost every failure comes down to five causes, all of them readable in the build log.
1. It works locally but not on Vercel. Vercel's servers run Linux, which treats uppercase and lowercase differently in file names. Importing Button when the file is called button works on Mac and Windows, and breaks on Vercel. Fix the casing and the problem disappears.
2. Blank page or 500 error after a successful build. Almost always a missing environment variable. Go back into Settings, add it, then trigger a new deployment: variables aren't applied retroactively.
3. The build can't find any files. Root Directory is set wrong. Point it at the subfolder that contains package.json.
4. Module not found even though the package is installed on your machine. The package-lock.json file wasn't pushed, or the dependency ended up in devDependencies even though the build needs it. Reinstall cleanly and push the code again.
5. The database doesn't respond. If your assistant created a SQLite database as a local file, it doesn't exist on Vercel. You need a database hosted online. Ask your assistant to migrate to a remote database before deploying rather than after.
In all five cases, the method is the same: copy the full error log, paste it to your assistant with the sentence „here's the Vercel build error, fix the project", and redeploy. If you want to understand the shape of a deployed Next.js project, the Next.js documentation is still the reference.
What you do once the app is live
You have a public URL, over HTTPS, that you can send to anyone. From there, two useful moves: hook up a custom domain name in the Domains tab if you own one, and get into the habit of pushing your changes to GitHub, since every push republishes the site automatically.
The first deployment is the only one that takes twenty minutes. The next one will take two, and you'll finally spend your time on what matters: what your app actually does for the people using it.
