Deploy a v0 app without Vercel

To deploy a v0 app without Vercel, connect the v0 chat to GitHub, copy its environment variables out of the Vercel project, set output: "standalone" in next.config, and build a Docker (opens in a new tab) image that runs node server.js. Run that image on your own server behind a reverse proxy such as Caddy, which serves your domain over HTTPS. This is one of the builder guides in deploying an AI-built app to your own server.

The v0 and Vercel facts here come from their documentation, checked on 11 November 2026. The Dockerfile and the Caddy and Compose files were built and run that day in Docker, on Node.js 22, against a fresh app from create-next-app (Next.js 16.4.6), the same framework v0 generates.

What v0 builds, and what is tied to Vercel

v0 writes apps with Next.js, React, TypeScript, Tailwind CSS and shadcn/ui. Its FAQ says plainly that you can export the code and deploy elsewhere, and recommends a Vercel-connected repository only for the full experience: environment variables, deployments and previews.

When you add Neon, Supabase or Upstash in v0, the Vercel Marketplace creates an account at that provider and adds its connection variables to the Vercel project. The database is the provider's, not Vercel's, so the app can keep using it after the move with the same variables. Run the app on your own computer with those values first: if it connects from there, it should connect from your server too, unless the provider only accepts listed IP addresses. Vercel Blob is Vercel's own storage; if the app uses it, check Vercel's docs for using it from outside Vercel, or move the files to other object storage.

Step 1: Connect the chat to GitHub

In v0, open the Project menu (the ...), then Settings, then GitHub. Choose Connect, pick the account or organisation, name the repository and choose Create Repository. v0 creates a private repository and pushes the project's current code to it.

From then on, a chat starts from a base branch (usually main). The first change in a chat creates a working branch, v0 pushes its changes there, and Publish merges a pull request into the base branch. If you keep building in v0 after the move, the base branch is the one your server should deploy from.

Clone the repository and run npm install and npm run build on your own computer first: a clean build there means the Docker build will work too.

Step 2: Collect the environment variables

v0 manages environment variables through Vercel: Project menu, then Settings, then Environment Variables. Make a list of every name, and sort it in two:

• NEXT_PUBLIC_ variables. Next.js inlines these into the JavaScript bundle during next build. They are public by design and must be present at build time.
• Everything else (DATABASE_URL, API keys, auth secrets). Next.js keeps these on the server and reads them when the app runs.

Vercel's CLI docs give Secret as the default type of a new Production variable, and a Secret's value cannot be read back from Vercel: vercel env pull writes a placeholder for it instead. Variables with a public prefix such as NEXT_PUBLIC_ are stored as Config, so those can be read and copied as they are. For each secret, go back to the service that issued it: the connection string from the Neon or Supabase dashboard, the key from Stripe, a newly generated value for your auth secret.

Step 3: Switch Next.js to standalone output

Next.js can trace exactly which files the server needs and copy them, with a minimal server.js, into .next/standalone. That makes the image much smaller than one with the whole node_modules. Add one line to next.config.ts (or next.config.js):

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  output: "standalone",
};

export default nextConfig;

Keep whatever else your config already has; only output is new.

Step 4: Add the Dockerfile

This is a shortened, npm-only version of the official example in the Next.js repository. The example uses a Node.js 24 Debian-based image; this one uses Node.js 22 on Alpine, the version this guide was tested with, and either works for Next.js 16:

# Dependencies: installed from the lockfile
FROM node:22-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --no-audit --no-fund

# Build: next build writes .next/standalone (output: "standalone")
FROM node:22-alpine AS build
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
# NEXT_PUBLIC_ variables are inlined into the bundle at build time
ARG NEXT_PUBLIC_SITE_URL
ENV NODE_ENV=production
RUN npm run build

# Run: only the standalone server, the static files and public/
FROM node:22-alpine AS run
WORKDIR /app
ENV NODE_ENV=production PORT=3000 HOSTNAME=0.0.0.0
COPY --from=build --chown=node:node /app/public ./public
COPY --from=build --chown=node:node /app/.next/standalone ./
COPY --from=build --chown=node:node /app/.next/static ./.next/static
USER node
EXPOSE 3000
CMD ["node", "server.js"]

Add one ARG line per NEXT_PUBLIC_ variable from step 2; NEXT_PUBLIC_SITE_URL is an example. If the repository uses pnpm or another package manager, the official example detects it from the lock file. Keep HOSTNAME=0.0.0.0 from the official example: the standalone server listens on the address in HOSTNAME, and 0.0.0.0 means every interface of the container, so the proxy can reach it.

A .dockerignore keeps local builds and env files out of the image:

node_modules
.next
.git
.env*

Step 5: Run it behind Caddy

Next.js's self-hosting guide recommends a reverse proxy in front of the Next.js server rather than exposing it directly. Caddy is a good fit because it also gets and renews the HTTPS certificate. The Caddyfile:

app.example.com {
	reverse_proxy app:3000
}

And compose.yaml, with the public values as build arguments and the runtime values from an env file:

services:
  app:
    build:
      context: .
      args:
        NEXT_PUBLIC_SITE_URL: ${NEXT_PUBLIC_SITE_URL}
    env_file: .env.production
    restart: unless-stopped

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
  caddy_config:

On the server, replace app.example.com with your domain, put the NEXT_PUBLIC_ values in .env (Docker Compose reads it for ${...}) and the server-side values in .env.production. Keep both out of Git. Point the domain's A record at the server and start it:

docker compose up -d --build

In our test, with localhost as the site address (Caddy then uses its own local certificate authority instead of a public one), the page showed the NEXT_PUBLIC_SITE_URL value passed at build time, the container received DATABASE_URL from .env.production at run time, the server ran as the node user, and /_next/image returned an optimised PNG. A public certificate for a real domain needs a real server, which the test did not use.

For more on the server side (provisioning, the firewall, deploying from GitHub Actions (opens in a new tab)), deploy Next.js to a VPS goes deeper on the same stack, and how to deploy a web app to a VPS covers the server from scratch.

Step 6: What changes when Next.js is not on Vercel

Most of Next.js works the same on one self-hosted server. Its self-hosting guide lists what to know:

• Images. next/image optimisation works with no configuration. On glibc-based Linux, the image library may need a memory allocator setting; the Alpine image above uses musl, not glibc.
• Proxy (formerly middleware) and after() work with no configuration on a Node.js server.
• Environment variables. Server code reads process.env at run time during dynamic rendering, so one image can run in several environments with different values. Only NEXT_PUBLIC_ values are fixed at build.
• Cache and ISR. The cache lives on the server's own disk, which is fine for a single server. If you later run several copies, they need a shared cache handler, the same NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, and a consistent build ID or deployment ID.
• Streaming. If you put nginx (opens in a new tab) in front instead of Caddy, turn off its response buffering for streaming to work.

Step 7: Check the Vercel-specific parts, then move the domain

1. Search the code for imports from @vercel/. Each is a Vercel product (analytics, storage and others); check its own docs for use outside Vercel, and remove or replace the ones that do not apply.
2. Search for vercel.app addresses in the code and in your variables: OAuth callback URLs, webhook endpoints (Stripe, GitHub), email links.
3. Add the new domain to every OAuth provider and auth service the app uses (Supabase's URL Configuration page, NextAuth's provider apps, and so on).
4. If vercel.json has redirects, rewrites or headers, move them to next.config (redirects, rewrites, headers), which works on any host.

Then point the domain at the server and remove it from the Vercel project. Own server vs Vercel compares the two hosting models side by side. The Claude Code guide covers the same Next.js apps when they come from a coding agent instead of v0, and the Bolt.new guide covers the static Vite case.

Doing this with OpsCrew

OpsCrew recognises a repository exported from v0 and builds its image with its own Next.js Dockerfile in GitHub Actions: a non-root image with every base image pinned, and NEXT_PUBLIC_ values handled as public build-time values. It deploys to a new server on Hetzner Cloud (opens in a new tab) or DigitalOcean (opens in a new tab) or to a server you already have, with HTTPS on your domain, and it translates the rules in vercel.json into the reverse proxy's configuration. A database the app already uses on Neon or Supabase can stay where it is, or OpsCrew runs PostgreSQL next to the app. A server-rendered Next.js app can also go on Cloudflare's hosting through OpenNext. Every change waits for your approval of its exact plan.

For what applies to every builder, see the guide to deploying an AI-built app to your own server.