Deployment turns project files into a website another person can open. A successful build is one checkpoint; the real goal is a page whose important actions work at the public URL. This walkthrough uses GitHub and Vercel for a small page with no database or login. You can apply the same checks with another host. Start with content you are comfortable making public and use the provider's generated domain before adding domain-management work.
What you will leave with
A working deployed page, a saved code checkpoint, a verified follow-up change and a clear way to recover the previous version.
Step 1
Confirm the local project is ready to publish
Open the page locally and complete its main action. Check the actual links, images, event details and narrow-screen layout. Ask your agent to identify the project framework and the commands already defined in its package file or README. For a framework project, run its production build before upload. A local development server working is useful evidence, but the production build can reveal different dependency or configuration problems.
Try this instruction
Inspect this project's README and package scripts. Identify the correct build command and output, then run the existing checks needed for a small public page. Report failures with evidence. Do not add accounts, a database, paid integrations or a different framework just to publish this version.
The main action works locally and the applicable production build finishes successfully.
Step 2
Save and inspect a code checkpoint
Use Git or GitHub Desktop to inspect the changed files before committing. Exclude local environment files, credentials and private source material. Commit a small working version with a descriptive message, then push the intended branch to the correct GitHub repository. A private repository does not make a deployed website private. Verify both the account that owns the repository and the content you intend to expose through hosting.
The repository contains the intended source and no secret or unrelated private file.
Step 3
Import the repository into the intended host project
In Vercel, create or select the intended project and import the repository using the supported Git integration. Review the account/team, root directory, detected framework and build settings. If several apps live in one repository, the root directory must point to this app. A plain page may need no framework-specific build. Review the current plan and any proposed paid feature instead of assuming every option is included.
You can identify the exact repository, branch, project and app directory being deployed.
Step 4
Inspect the environment before the first deployment
Vercel's current documentation says a new project's first deployment is production, even when started without the production flag. Do not assume a first upload is a private preview. For later changes, distinguish development, preview and production. Add environment variables only if the app needs them, and put each value in the intended environment. Keep administrative secrets on the server. A simple public page usually needs none.
You know whether this deployment will be public and which configuration it will use.
Step 5
Deploy, then read the actual result
Start the deployment and wait for its terminal result. If it fails, open that deployment's build log and identify the specific error before asking for a fix. The final line saying a command exited is often only a summary. Fix one cause, rerun the local check and redeploy. When successful, save the deployment URL and code revision so you can match the website to the source that produced it.
The host reports a successful deployment for the revision you intended to publish.
Step 6
Check it as a visitor
Open the exact deployed URL in a fresh browser session and on a phone or narrow viewport. Follow the main link, reload an inner page if there is one, inspect the images and try keyboard navigation. Check the page title and sharing preview. If access protection is intentional, verify the expected access flow rather than disabling it reflexively. Record what you checked and what remains untested before sharing widely.
A person in the intended audience can open the page and complete its main action.
Step 7
Practice one update and learn recovery
Make a harmless text change on a new branch and review its preview deployment. Once checked, merge through the project's normal process and verify production again. Locate the previous working deployment and the matching Git checkpoint. Vercel offers rollback subject to deployment eligibility; it restores an earlier build, not your database contents. Knowing the recovery path before an urgent problem makes future changes easier to manage.
You can explain how a change reaches production and identify the previous working version.
When you get stuck
The host builds the wrong app
Compare the project's root directory and repository branch with the actual app location.
A variable works locally but is missing online
Check its name and environment scope. Redeploy after correcting configuration; do not expose a secret to silence an error.
The deployment is green but a button is broken
Treat build success and user behavior as separate checks. Reproduce the failed action on the deployment URL.
Terms explained
- Deployment
- A built version of your project running at a host-provided address.
- Preview
- A deployment intended to inspect a change before the main live site uses it.
- Production
- The version intended for real visitors and live operation.
Sources and further reading
The workflow and templates are teaching guidance. The sources below support the underlying tools and concepts; product setup and availability can change.
Take it into your next task
Your completion checklist
0 / 7 checked
Checks are saved on this browser. Mark them only after you inspect the evidence. These are your checks, not an automated certification.