Vercel

What Vercel Is

That wider view matters because deployment is more than "the page loads." A real project needs a repeatable path from source code to a public URL. It needs a way to test changes before they affect users. It needs a production domain that can be moved, verified, and secured. It needs secrets that are not committed to Git. It needs logs when the build fails or a server-side route throws an error. Vercel brings those concerns into one project dashboard and connects them to a Git repository.

This track teaches Vercel as a deployment platform for frontend and full-stack web apps. You will see static sites, React and Vite apps, Next.js apps, API routes, serverless functions, domains, redirects, rewrites, headers, .vercelignore, vercel.json, deployment protection, logs, analytics, cron jobs, and storage choices. The track is useful even if you do not use Next.js. Vercel works especially well with Next.js, but frontend developers also use it for static sites, Vite builds, Astro sites, marketing pages, dashboards, documentation sites, and small full-stack applications.

The Core Mental Model

A Vercel project connects source code, build settings, deployments, domains, and runtime configuration.

The source code usually lives in a Git provider such as GitHub, GitLab, Bitbucket, or Azure DevOps. When Vercel is connected to the repository, a push or pull request can create a deployment automatically. Vercel runs the install and build steps, stores the build output, assigns a generated deployment URL, and applies the environment variables and project settings selected for that deployment environment.

The important nouns are:

  • Project: the Vercel configuration for one deployed app or site.
  • Deployment: one built version of the project, usually tied to a commit.
  • Preview Deployment: a deployment for review, QA, collaboration, or branch testing.
  • Production Deployment: the deployment served to the real production domain.
  • Production Branch: the Git branch that normally creates Production Deployments, often main.
  • Build Command: the command that creates deployable output, such as npm run build.
  • Output Directory: the directory Vercel serves after the build, such as dist.
  • Environment Variables: runtime or build-time configuration stored outside source code.
  • Vercel Functions: server-side request handlers that can power APIs, webhooks, forms, or private service calls.

Once those words are clear, Vercel feels less mysterious. You are not "putting a folder on the internet." You are producing a deployment artifact from a known commit, applying environment-specific configuration, and deciding whether that artifact is for preview or production.

Static Sites, Frontend Apps, And Full-Stack Apps

Vercel can serve a plain static site. A folder with index.html, CSS, images, and JavaScript can become a public website. For a beginner, this is the fastest way to learn the deployment loop: change a file, build or upload the project, get a URL, and verify the page in a browser.

Vercel can also serve a frontend application built by tools such as Vite. In that workflow, the source files are not the same as the deployed files. Your repository might contain src/App.jsx, package.json, and configuration files. The build command creates a dist/ folder. Vercel serves the generated assets from that output directory. If the app uses client-side routing, you may also need a rewrite so browser refreshes on paths like /settings return the app shell instead of a 404.

For full-stack projects, Vercel can run server-side code through Vercel Functions or framework-specific routes. A contact form might post to a function that validates input and calls an email API. A Stripe webhook might call a function that verifies the signature before updating a database. A dashboard might fetch private data through a server-side route instead of exposing an API key in browser JavaScript.

This is why the track will not treat Vercel as only a static host. Static output is one important case, but production apps often need a mix of static assets, generated pages, server-side routes, private secrets, logs, domains, and cost controls.

Git-Based Deployments

The most common Vercel workflow starts with Git. You import a repository, choose the project settings, and let Vercel create deployments from commits and pull requests. A change pushed to a feature branch can create a Preview Deployment. A merge or push to the Production Branch can create a Production Deployment.

That workflow changes how teams review work. Instead of asking someone to pull a branch and run the app locally, you can share a preview URL. Designers can inspect layout changes. Clients can approve copy. Developers can test a form flow against preview credentials. Product owners can compare behavior before the change reaches production.

Git-based deployment also creates a useful audit trail. When a bug appears, the team can ask which commit was deployed, which build command ran, and which environment variables were active. That evidence is better than guessing what files someone uploaded by hand.

Local, Preview, And Production

Vercel uses three default environment concepts: local development, preview, and production.

Local development happens on your machine. You edit code, run a dev server, and test quickly before pushing. Some projects use the Vercel CLI to make local behavior closer to the hosted environment, especially when functions or Vercel-managed environment variables are involved.

Preview is for deployed work that is not the public production site. Preview Deployments are useful for pull requests, QA checks, client review, and branch-specific testing. A preview URL can still be public unless you protect it, so do not assume "not production" means "private." Later lessons cover Preview Deployment Protection and safe sharing.

Production is the user-facing environment. It is where the public domain points, where SEO and analytics matter, and where mistakes can affect users or customers. Production should use production secrets, production database connections, and production monitoring. A personal test key that works in Preview should not silently become the live payment, email, or database credential.

The Commercial-Use Warning

Vercel has a free Hobby plan, but free does not mean unrestricted. Vercel describes the Hobby plan as aimed at personal projects and small-scale applications, and its fair-use guidance restricts Hobby usage to non-commercial personal use. That distinction belongs early in the course because many beginners hear "Vercel is free" and apply it to client or business projects without checking the plan terms.

For this track, treat the Hobby plan as suitable for learning, demos, experiments, personal portfolios, and non-commercial projects within the current limits. For commercial, client, business, paid, ad-supported, internal company, or production business projects, check Vercel's current pricing, plan terms, usage limits, and billing controls before deploying. A small project can still create billable or plan-limited usage through bandwidth, function invocations, image optimization, analytics events, build minutes, storage, or logs.

The practical rule is simple: do not sell Vercel to a client as "free hosting." Explain the deployment platform, explain the plan choice, and make billing ownership explicit. If a client owns the project, the client should usually own the Vercel team, domain, billing, and production credentials. Your personal Hobby account should not become the hidden production infrastructure for someone else's business.

What Vercel Handles For You

Vercel removes a lot of server administration from common frontend deployments. You usually do not configure Nginx, install TLS certificates by hand, copy files over SSH, or keep a long-running Node process alive for a simple frontend app. The platform builds the project, serves static assets through its infrastructure, provisions generated URLs, manages HTTPS for configured domains, and runs functions according to the selected runtime and project settings.

That does not mean there is nothing to learn. Managed platforms move work from server setup into project configuration and operational judgment. You still need to know which branch deploys to production, which variables are public, which files are shipped, how redirects work, whether a route is static or server-side, how logs are retained, which plan limits apply, and how to roll back when a bad deployment goes live.

This course will keep returning to that tradeoff. Vercel can make deployment faster, but speed is only useful when the workflow is understandable and reversible.

What Vercel Does Not Magically Solve

Vercel does not make insecure code safe. If browser JavaScript contains an API key, the key is public. If a function accepts webhook requests without verifying signatures, Vercel does not fix the trust problem. If a preview deployment exposes private client work without protection, the generated URL is still a URL someone could share. If a build process depends on an unpinned package or a missing environment variable, the deployment can fail.

Vercel also does not remove the need for data design. User uploads should not be stored by committing files to the repository. Database credentials should not live in source code. Private certificates, service account JSON, .env files, and database dumps do not belong in Git. Later lessons cover Vercel Blob, Edge Config, database integrations, and safe server-side access patterns, but the core principle starts now: source control is not a secret store and not an upload bucket.

A Small Deployment Picture

A typical beginner Vite deployment might look like this:

Repository
  package.json
  src/
  public/

Vercel project settings
  Framework preset: Vite
  Build command: npm run build
  Output directory: dist
  Production branch: main

Deployments
  feature branch -> Preview Deployment
  main branch -> Production Deployment

For a plain static site, there may be no framework build:

Repository
  index.html
  styles.css
  scripts.js

Vercel project settings
  Build command: none or project-specific
  Output directory: project root or configured output folder

For a small full-stack app, the picture adds server-side routes:

Repository
  app/
  api/
    contact.ts
  package.json

Vercel project settings
  Environment Variables:
    EMAIL_API_KEY
    CONTACT_TO_ADDRESS

Runtime behavior
  Browser posts form data to /api/contact
  Vercel Function validates input
  Function calls email provider with server-side secret

The details vary by framework, but the deployment reasoning is the same. Know what is public, what is server-side, what gets built, what gets configured per environment, and what evidence proves the deployment worked.

Where This Track Goes Next

The next lesson focuses on Free vs Pro so you can choose a plan responsibly before teaching or using the platform for real work. After that, the track moves through first static deployments, GitHub integration, Preview vs Production Deployments, domains and HTTPS, Environment Variables and secrets, public files versus private server files, .vercelignore, vercel.json, build logs, routing rules, React/Vite deployments, Next.js deployments, Vercel Functions, private API calls, deployment protection, preview comments, analytics, image optimization, cron jobs, storage, monorepos, security, cost control, and two real project deployments.

The goal is not to memorize every Vercel setting. The goal is to understand how modern deployment platforms connect source code, build output, environments, domains, server-side behavior, security boundaries, and cost. If you can explain those boundaries, Vercel becomes a practical tool instead of a magic button.

Review Questions

  • What is the difference between a Vercel Project and a Deployment?
  • Why is "free hosting" an inaccurate way to describe Vercel?
  • Which kinds of work belong in Preview Deployments instead of Production Deployments?
  • Why should commercial, client, business, paid, ad-supported, or production business projects check paid plan requirements?
  • What information should you confirm before deploying a frontend app with a build step?
  • Which secrets must stay out of browser JavaScript and source control?

Official References