What Is Deployment? Getting Your AI-Built App From Your Computer to the Internet

Why AI Coders Need to Know This

AI is extraordinary at building apps. Ask Claude or Cursor to scaffold a project management tool, a client intake form, or a real estate listing site, and you will have working code in minutes. What AI cannot do is ship that code to the internet for you. That last step — deployment — is entirely on you.

This is the most common place vibe coders get stuck. The app works beautifully on localhost. You run npm run dev, open the browser, click around, everything works. Then you share your screen with a client or a friend and realize: only you can see it. Your laptop is not a server. Nobody else has access to port 3000 on your machine.

Deployment is the bridge. It is the process of taking your app off your computer and putting it somewhere the entire internet can reach. In construction terms: deployment is like getting the certificate of occupancy. The building is done, all the inspections are passed, the keys are cut. Now it is time to open the doors and let people in.

Understanding deployment also protects you. Without it, you will push to production with missing secrets, hardcoded localhost URLs, or a broken build step — and you will not know why your app works locally but 500s in production.

Real Scenario: Your Next.js App Is Ready — Now What?

You have been building a neighborhood contractor referral platform with Cursor. It is a Next.js app with a home page, a search page, and a contact form that sends emails via Resend. You have been developing on your MacBook. The terminal shows:

▲ Next.js 15.2.0
- Local:        http://localhost:3000
- Environments: .env.local

✓ Ready in 1.2s

You open a browser and the app loads. You test the search. The contact form sends. Everything works.

Then a friend asks: "What's the URL? I want to check it out." You realize you do not have one. The app only runs on your computer, while your terminal is open, while you are on your home network. It is not "on the internet." It lives at an address — localhost:3000 — that only your machine understands.

What you need to do is deploy.

My Next.js 15 app is working locally. I want to deploy it to Vercel.
It uses:
- A PostgreSQL database (via Supabase)
- Resend for email
- Environment variables in .env.local

Walk me through exactly what I need to do, including:
1. What to check before deploying
2. How to handle my environment variables
3. How to set up the Vercel project
4. What to watch for in the build logs

This is a good prompt. It gives AI the full context it needs — the framework, the services, the secrets situation. The AI will generate a checklist and a deployment config. Let us look at what it typically produces and what each piece does.

What AI Generated: A Deployment Config

When you ask an AI tool to help prepare a Next.js app for deployment, it will often produce a vercel.json configuration file along with deployment instructions. Here is a realistic example:

{
  "version": 2,
  "framework": "nextjs",
  "buildCommand": "npm run build",
  "outputDirectory": ".next",
  "env": {
    "NODE_ENV": "production"
  },
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        {
          "key": "X-Content-Type-Options",
          "value": "nosniff"
        },
        {
          "key": "X-Frame-Options",
          "value": "DENY"
        }
      ]
    }
  ]
}

And the deployment checklist might include a pre-deploy script like this in package.json:

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint",
    "predeploy": "npm run lint && npm run build"
  }
}

Let us break down what each piece is actually doing.

Understanding Each Part

What Deployment Actually Does (In Plain English)

Deployment has four steps, even when a platform like Vercel hides them from you:

1. Build — Your source code (JSX, TypeScript, unoptimized images) is compiled into static files and server functions a browser or server can actually execute. This is the npm run build step.
2. Upload — The compiled output is sent to a server (or a CDN) that is always connected to the internet.
3. Configure — The server is told how to handle incoming requests: which URLs map to which pages, which routes run server code, and which secrets to use.
4. Point DNS — A domain name is pointed at the server's IP address so humans can type yourapp.com instead of 123.45.67.89.

Platforms like Vercel automate steps 1 through 4 entirely. You push code to GitHub, Vercel detects the push, runs the build, uploads the result, configures the routing, and updates the URL. That is why it feels magical — but all four steps still happen.

Localhost vs. Production: What Is Actually Different

Your local development environment and a production deployment are not the same thing, even when running the same code. The differences that trip people up most:

• Environment variables — Your .env.local file stays on your computer. It is deliberately not committed to Git (you have a .gitignore entry for it). Production does not have it. You must manually add your secrets to the hosting platform's dashboard.
• Node.js version — Your laptop might run Node 22. Your hosting provider might default to Node 18. Minor differences can cause subtle failures.
• File system access — Writing files to disk works on your laptop. On serverless platforms like Vercel, your functions are stateless and cannot write to the local file system between requests. If your AI-generated code writes temporary files, this will break.
• URLs — Any hardcoded http://localhost:3000 in your code will fail in production. Use environment variables for base URLs.
• HTTPS — Production URLs use HTTPS. Some browser features (camera, geolocation, clipboard) only work over HTTPS. They will work on localhost, fail in production unless HTTPS is configured.

The Build Step Explained

When you run npm run dev locally, Next.js compiles your code on the fly, as you edit it. This is slow if done once, but fast to iterate — every save recompiles just the changed file.

Production does not work this way. Before deploying, you run npm run build, which:

• Compiles all TypeScript to JavaScript
• Optimizes images and fonts
• Generates static HTML for pages that do not need server code
• Bundles JavaScript into the smallest possible files
• Runs a type check and catches obvious errors

If the build fails, your deployment fails. This is actually useful — it is the first automated check that your code is correct. Build errors are your friend. They catch problems before users see them.

Static vs. Dynamic Deployment

Not all apps need a running server. Understanding this distinction affects which hosting option makes sense:

• Static deployment — Pre-built HTML, CSS, and JS files served from a CDN. No server executes code per request. Fast, cheap, globally distributed. Works for portfolios, marketing sites, blogs, and docs.
• Dynamic deployment — A server runs code for every request, or per function call. Necessary for apps that fetch user-specific data, handle authentication, process payments, or talk to a database at request time.
• Hybrid (what Next.js does) — Some pages are static, some are dynamic. A marketing home page might be fully static. The dashboard behind login is dynamic. Next.js handles both in the same project.

The Deployment Options Landscape

You have five realistic options for deploying a Next.js app. Each has a different complexity-vs-control tradeoff.

Vercel — Easiest for Next.js

Vercel built Next.js, so deploying Next.js on Vercel is the path of least resistance. Connect your GitHub repo, set your environment variables, click Deploy. Vercel handles the build, CDN distribution, automatic HTTPS, and preview deployments for every pull request. The free tier covers most personal and small commercial projects.

Read more: What Is Vercel?

Netlify — Best for Static and Jamstack Sites

Netlify is the original static-site deployment platform. It also supports serverless functions, form handling, and identity features. It is excellent for static sites, Gatsby apps, or sites where the server-side requirements are minimal. Next.js works on Netlify but requires a community-built adapter — it is not as native as Vercel.

Read more: What Is Netlify?

Railway — Best for Full-Stack and Backends

Railway deploys apps as persistent containers, not serverless functions. This makes it the right choice when you need a long-running server process, a background job queue, or a database running alongside your app. Next.js works well here. So does a standalone Express or FastAPI backend. Railway's free tier is usage-based and generous for small projects.

VPS (Virtual Private Server) — Full Control, Full Responsibility

A VPS is a virtual machine in a data center. You get root access — you install Node.js yourself, configure Nginx yourself, set up SSL yourself, manage security yourself. This is the most powerful option and the most complicated. Most vibe coders do not need a VPS until they hit platform limitations or have specific compliance or infrastructure requirements.

Comparison Table

What AI Gets Wrong About Deployment

AI generates deployment configs confidently. That confidence is not always warranted. Here are the most common AI-generated deployment mistakes.

Missing Environment Variables in Production

This is the number-one deployment failure for AI-built apps. AI will generate code that reads from process.env.RESEND_API_KEY or process.env.DATABASE_URL. Locally, those values come from your .env.local file. In production, that file does not exist.

You must manually add every environment variable to your hosting platform. In Vercel: Settings → Environment Variables. Miss one and your app will silently fail or crash on any code path that uses it.

Dev-Only Packages and Settings

AI sometimes installs packages in dependencies that should be in devDependencies, and vice versa. More dangerously, it sometimes generates code that uses development-specific behavior — like connecting to a local database on localhost:5432 — without making that configurable. In production, localhost:5432 points to nothing.

Always check: any URL, host, or port that points at your local machine needs to be an environment variable.

CORS Issues

AI-generated API routes often have permissive CORS settings that work in development (Access-Control-Allow-Origin: *) but cause security warnings or failures when deployed. When your frontend is on yourapp.vercel.app and your API is on a different domain, CORS configuration becomes critical. AI often misses this entirely.

Build Failures the AI Did Not Test

AI generates code but does not run it through a production build. TypeScript type errors, missing imports, and incompatible package versions that do not break npm run dev will break npm run build. The AI-generated code looked fine in your editor. The CI build fails.

Always run npm run build locally before pushing to a deployment pipeline. It takes 30 seconds and catches a class of errors that would otherwise surface as a confusing cloud build failure.

Step-by-Step: Deploy a Next.js App to Vercel

This is the fastest path from localhost to the internet for a Next.js app. Follow it in order.

Step 1: Push Your Code to GitHub

Vercel deploys from a Git repository. If your project is not already on GitHub, create a repo and push your code. Make sure your .gitignore includes:

# These must NOT be in your git repo
.env
.env.local
.env.production
node_modules/
.next/

If you accidentally committed a .env file, remove it from Git history before pushing. Your API keys are now compromised — rotate them.

Step 2: Collect Your Environment Variables

Open your .env.local and write down every key-value pair. You will need to enter them in Vercel. Example:

DATABASE_URL=postgresql://user:password@db.supabase.co:5432/postgres
RESEND_API_KEY=re_xxxxxxxxxxxx
NEXTAUTH_SECRET=your-random-32-char-string
NEXTAUTH_URL=https://yourapp.vercel.app   # ← update this to your Vercel URL

Notice that NEXTAUTH_URL changes between environments. Locally it is http://localhost:3000. In production it is your real HTTPS URL. This is why environment variables exist — to let the same code behave differently in different environments.

Step 3: Run a Local Build to Check for Errors

npm run build

If this succeeds, your code is deployable. If it fails, fix the errors before touching Vercel. Common build errors and what to tell AI:

Type error: Property 'x' does not exist on type 'Y'
→ Prompt: "Fix this TypeScript error: [paste full error]. Here is the component: [paste code]"

Module not found: Can't resolve 'some-package'
→ Prompt: "I'm getting this build error. Is this package in the wrong dependency type? [paste error]"

Step 4: Connect to Vercel

1. Go to vercel.com and sign in with your GitHub account.
2. Click "Add New Project" and import your GitHub repository.
3. Vercel detects Next.js automatically. Do not change the framework setting.
4. Before clicking Deploy, open "Environment Variables" in the project setup screen.
5. Add every key-value pair from your .env.local. Set scope to "Production, Preview, Development" for each one.
6. Click Deploy.

Step 5: Read the Build Logs

Vercel shows a live build log. Watch for these signals:

✓ Compiled successfully          → Build passed, all good
⚠ Warning: missing env variable  → Check your environment variables
✗ Build failed                   → Read the error above, fix it, push again
Function size exceeds limit       → One of your API routes is too large

When the build succeeds, Vercel gives you a URL like your-project.vercel.app. Click it. Test every page and form flow. Check the browser console and the Vercel function logs for runtime errors.

Step 6: Add a Custom Domain (Optional)

In your Vercel project: Settings → Domains → Add. Follow the instructions to update your DNS records at your domain registrar. Vercel handles the HTTPS certificate automatically. Within minutes, yourapp.com is live.

Need to understand DNS? Read: What Is DNS?

Common Deployment Errors and What They Mean

These are the errors you will encounter. Here is what they mean in plain English and the prompt to fix them.

"Error: ENOENT: no such file or directory"

What it means: Your code is trying to read a file that exists on your laptop but was not deployed. Usually a local asset, a JSON config file not in the repo, or a path relative to your home directory.

Fix prompt: "In production on Vercel I get ENOENT for [path]. The file exists locally. How do I make this accessible in production — should it be in the public directory, committed to the repo, or loaded differently?"

"Application error: a server-side exception has occurred"

What it means: Your Next.js server-side code threw an uncaught error. The client just shows a generic message. The real error is in your Vercel function logs.

Fix prompt: "My Vercel function logs show this error: [paste from Vercel dashboard]. Here is the relevant route: [paste code]. What is causing this and how do I fix it?"

"Build failed: Command 'npm run build' exited with 1"

What it means: The build step crashed. Scroll up in the build log to find the actual error — this message is the result, not the cause.

Fix prompt: "My Vercel build is failing. Here is the full build log: [paste]. Identify the root cause and tell me how to fix it."

"504 Gateway Timeout"

What it means: A request to your server-side function took too long. Vercel functions have a 10-second default timeout. Database queries that are fast locally can be slow in production due to cold starts or unindexed queries.

Fix prompt: "My Vercel function is timing out at 10 seconds. Here is the function: [paste code]. It queries a Supabase database. How do I optimize this query and handle the timeout gracefully?"

"ReferenceError: window is not defined"

What it means: You are using browser-only APIs (like window, document, or localStorage) in server-side code. Locally, Next.js is more forgiving. In production, it fails hard.

Fix prompt: "I'm getting 'window is not defined' in my Next.js component during build. The component uses [describe usage]. How do I refactor this to work on both server and client?"

"CORS policy: No 'Access-Control-Allow-Origin' header"

What it means: Your frontend (on domain A) is making API requests to a backend (on domain B), and the backend has not explicitly allowed that. This does not appear locally because you are on the same domain.

Fix prompt: "I'm getting a CORS error in production. My frontend is on [frontend URL] and API is on [api URL]. Here is my API route: [paste]. How do I configure CORS headers correctly for production while keeping it secure?"

What to Learn Next

Deployment opens the door to a full infrastructure education. Once your app is live, the natural next questions are:

• What Is an Environment Variable? — understand secrets, configs, and why the same code behaves differently in different environments.
• What Is DNS? — how domain names translate to IP addresses, and how to point your domain at your Vercel deployment.
• What Is HTTPS / SSL? — why the padlock matters and how Vercel handles certificates for you.
• What Is Vercel? — a deeper look at the platform, its pricing, limits, and when to consider an alternative.
• What Is Netlify? — how it compares to Vercel and when it is the better choice.
• What Is a VPS? — when you need your own server and what that actually means.
• What Is Git? — every deployment pipeline starts with git. Understand commits, branches, and push so deployment becomes a single command.
• Security Basics for AI Coders — your app is now public. Learn what to lock down before someone finds it.
• What Is Application Monitoring? — how to know when your app breaks before your users do. Set up error tracking, uptime alerts, and performance monitoring.
• What Is Application Logging? — your app's daily report. When something crashes at 3 AM, logs are how you figure out what happened.

FAQ