Think of this as three boxes. Cursor is where you edit the site. GitHub is the safe copy with history. Vercel is the public version people open in a browser. If each box is in order, you can update the site without being afraid of losing it.
What you will have
- A GitHub repository that stores the site safely
- A Vercel project with a working public URL
- A clear list of private settings such as form keys or email tokens
- A simple update routine: edit, save, deploy, check
- A rollback path if a new version breaks the site
● Steps
From Cursor to a live website: GitHub and Vercel without panic
Prepare the project before publishing
Open the site in Cursor and make sure it starts locally. Find the command in package.json, usually npm run dev. Open the local address in a browser and click through the important pages. Result: you know the project is not already broken before GitHub or Vercel enters the picture.
Create a GitHub repository
Go to GitHub, create a new repository and give it a simple name, for example bakery-website or clinic-site. Keep it private if the project is unfinished. Result: you have an empty online folder where the site will be saved with history.
Save the first version of the code
In Cursor, open the Source Control panel or terminal. Add the files, write a short message such as first working version, and push to GitHub. Do not make the first save together with ten unrelated experiments. Result: GitHub now contains the same project you have on your computer.
Import the repository into Vercel
Open Vercel, choose Add New Project, select the GitHub repository and let Vercel detect the framework. Before clicking Deploy, check the build command and output settings that Vercel shows. Result: Vercel builds the site from GitHub instead of from your laptop.
Add private settings in Vercel
If the site has a form, email sending, analytics or a paid API, add those keys in Vercel Project Settings -> Environment Variables. Never paste private keys into normal code files. Result: the public site can use private services, but visitors cannot see the secrets.
Check the live URL like a customer
Open the Vercel URL on a phone and desktop. Test the menu, buttons, form, thank-you message, page speed feeling and obvious spelling mistakes. Send a test form submission to yourself. Result: you confirm that the site works for a real visitor, not only inside Cursor.
Use a safe update routine
For each future change: edit in Cursor, check locally, save a small commit, push to GitHub, wait for Vercel preview, then check production. If the new version breaks something, open Vercel Deployments and promote the previous working deployment. Result: you can improve the site without guessing how to recover.
Common failure points
- Keeping the only copy of the project inside Cursor or a Downloads folder
- Publishing before checking that the site runs locally
- Putting private keys directly into code files
- Changing settings in Vercel and forgetting to write down what changed
- Not testing the live form after deployment
- Making huge mixed commits that are hard to undo
Deployment stuck or scary?
Send the GitHub link, Vercel project screenshot and the live URL. I can find where the chain breaks and leave you with a repeatable publishing routine.
- Build fails and the error is unclear
- Environment variables are missing or duplicated
- The live site works differently than Cursor
- You need a safe rollback before changing production
● Related guides
Related guides
Do not want to pay for a website? Build it yourself.
A practical path from idea to live website with AI-assisted coding, GitHub, Vercel, domain, form and SEO basics.
TAPE-03Prompts for Cursor that do not produce junk
Prompt structure for small business sites: context, sections, constraints, checks and edit loop.
TAPE-04Why AI websites look like cheap demos
The repeatable failure pattern: fake copy, weak offer, broken mobile, no forms, no indexing.