How to Integrate Docker with V0

Before adding Docker, you need the V0-generated code on your local machine. In the V0 interface, open the Git panel in the left sidebar and connect your GitHub account if you haven't already. Click 'Push to GitHub' to create a new repository with your V0 project code. V0 creates a branch named `v0/main-{hash}` and submits a pull request — merge this into main to get the code into your primary branch. Once the repository exists on GitHub, open your terminal and clone it: `git clone https://github.com/your-username/your-repo-name.git`. Navigate into the project directory with `cd your-repo-name`. Run `ls` to verify the standard Next.js file structure is present: `app/`, `components/`, `package.json`, `tsconfig.json`, and `next.config.js` (or `next.config.ts` in newer V0 exports). Before adding Docker, run `npm install` and `npm run dev` to confirm the app works locally without Docker. This baseline check ensures any issues you encounter later are Docker-specific rather than code issues. If `npm run dev` fails, fix those issues first — Docker won't fix underlying code problems. Check the Node.js version requirement in package.json. V0-generated projects typically require Node.js 22 based on the CLAUDE.md specification. Your Dockerfile should use the matching Node.js version to ensure build/runtime parity.

The most important step for an efficient Docker setup is enabling Next.js's standalone output mode. Open `next.config.js` (or `next.config.ts`) in your project root and add `output: 'standalone'` to the Next.js configuration. This instructs `next build` to produce a self-contained output in `.next/standalone/` that includes only the files needed to run the app — typically reducing the Docker image from 500MB+ to under 100MB. Standalone mode works by tracing all imports and copying only the required files, replacing the full `node_modules` with a minimal subset. The resulting `.next/standalone/server.js` is a complete Node.js HTTP server that doesn't need the original project directory at all. After enabling standalone output, also configure the output for public assets. The standalone build doesn't automatically include the `.next/static/` directory or the `public/` folder — these need to be copied into the container separately in your Dockerfile. This is a common gotcha that results in missing CSS, fonts, and images if you overlook it. If your V0 project already has a next.config.js with existing configuration (image domains, environment variables, redirects), add `output: 'standalone'` without removing the existing config. The output setting is purely a build optimization and doesn't affect how the app behaves — it only changes what files are included in the build output.

1// next.config.js — add output: 'standalone'
2/** @type {import('next').NextConfig} */
3const nextConfig = {
4  output: 'standalone', // Add this line
5  // Keep any existing configuration below:
6  images: {
7    remotePatterns: [
8      // your existing image domains
9    ],
10  },
11  // any other existing config...
12};
13
14module.exports = nextConfig;

Create a `Dockerfile` in your project root. Use a multi-stage build to keep the final image small and secure: the first stage installs dependencies and builds the app, the second stage is the lean production runtime that only contains what's needed to run the server. For the base image, use `node:22-alpine` — Alpine Linux is a minimal Linux distribution that produces significantly smaller images than `node:22-bullseye` or `node:22` (typically 50-80MB vs 200-400MB). Node.js 22 matches V0's requirements per the CLAUDE.md specification. The build stage runs `npm ci` (for reproducible installs using package-lock.json) and `npm run build`. The `npm ci` command is preferred over `npm install` in CI/Docker environments because it strictly follows the lockfile, ensuring identical dependency versions every build. The production stage copies only the standalone output directory, the public folder, and the static assets from the build stage. Set `NODE_ENV=production` and run `node server.js` to start the app. The `EXPOSE 3000` instruction is documentation only — it doesn't actually publish the port (that's done with `-p` flag when running the container). For security, avoid running the server as root. Create a non-root user `nextjs` in the production stage and switch to it before the CMD instruction. This follows container security best practices and is required by some deployment platforms.

1# Dockerfile
2FROM node:22-alpine AS base
3
4# Install dependencies stage
5FROM base AS deps
6RUN apk add --no-cache libc6-compat
7WORKDIR /app
8COPY package.json package-lock.json* ./
9RUN npm ci
10
11# Build stage
12FROM base AS builder
13WORKDIR /app
14COPY --from=deps /app/node_modules ./node_modules
15COPY . .
16ENV NEXT_TELEMETRY_DISABLED=1
17RUN npm run build
18
19# Production runtime stage
20FROM base AS runner
21WORKDIR /app
22ENV NODE_ENV=production
23ENV NEXT_TELEMETRY_DISABLED=1
24
25# Create non-root user for security
26RUN addgroup --system --gid 1001 nodejs
27RUN adduser --system --uid 1001 nextjs
28
29# Copy public folder
30COPY --from=builder /app/public ./public
31
32# Set correct permissions for standalone files
33RUN mkdir .next
34RUN chown nextjs:nodejs .next
35
36# Copy standalone build output
37COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
38COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
39
40USER nextjs
41EXPOSE 3000
42ENV PORT=3000
43ENV HOSTNAME=0.0.0.0
44
45CMD ["node", "server.js"]

Create a `.dockerignore` file to exclude unnecessary files from the Docker build context. Without this file, Docker sends your entire project directory — including `node_modules` (which can be hundreds of MB), `.next` build cache, `.git` history, and any `.env` files — to the Docker daemon before every build. This dramatically slows down builds and risks accidentally including sensitive files in the image. For local development, create a `docker-compose.yml` that defines how to run your V0 app along with any supporting services. Docker Compose makes it easy to pass environment variables, mount volumes for hot reloading, and add services like PostgreSQL or Redis that your app depends on. The `docker-compose.yml` should map port 3000 inside the container to port 3000 on your local machine (`3000:3000`). For development, mount your local `app/` and `components/` directories as volumes so code changes are reflected without rebuilding the image — though this requires running with `npm run dev` mode rather than the production standalone server. For environment variables, never commit `.env` files to Git. Instead, create a `.env.example` file with placeholder values and document which environment variables are required. Team members copy this to `.env.local` and fill in real values. In `docker-compose.yml`, reference the `.env` file using `env_file: .env.local` to load variables at container startup. A common pattern for teams is having two Compose files: `docker-compose.yml` for production-like local testing (uses the production Dockerfile) and `docker-compose.dev.yml` for development (uses `npm run dev` with volume mounts for hot reloading). Run with `docker-compose -f docker-compose.dev.yml up` for development.

1# .dockerignore
2Dockerfile
3.dockerignore
4node_modules
5.next
6.git
7.gitignore
8.env
9.env.local
10.env.*.local
11README.md
12*.md
13.DS_Store
14
15---
16# docker-compose.yml (for production-like local testing)
17version: '3.8'
18services:
19  app:
20    build:
21      context: .
22      dockerfile: Dockerfile
23    ports:
24      - '3000:3000'
25    env_file:
26      - .env.local
27    environment:
28      - NODE_ENV=production
29    restart: unless-stopped

Build and test the Docker image locally before pushing to a registry for deployment. Run `docker build -t my-v0-app .` from your project root and watch for any build errors. Common issues include missing environment variables (which cause next build to fail if they're required at build time) and missing system dependencies for native npm packages. After a successful build, run `docker run -p 3000:3000 --env-file .env.local my-v0-app` to start the container. Open your browser to localhost:3000 and verify the app loads correctly. Check that CSS styles load (confirming the `.next/static` directory was copied), images load (confirming the `public` directory was copied), and API routes work. To check the container image size, run `docker images my-v0-app`. A well-optimized standalone Next.js app with Node.js Alpine should be 80-150MB. If the image is much larger, verify that the multi-stage build is actually being used and the `.next` cache isn't being copied into the final stage. For deploying to a container registry, tag the image with your registry URL: `docker tag my-v0-app registry.example.com/my-v0-app:latest` and push with `docker push registry.example.com/my-v0-app:latest`. For Docker Hub: `docker tag my-v0-app username/my-v0-app:latest && docker push username/my-v0-app:latest`. For Google Container Registry: tag with `gcr.io/your-project/my-v0-app` and push. The deployment process from there depends on your target platform (Cloud Run, ECS, Kubernetes, etc.) but the Docker image is the same regardless of where you deploy it. For teams using CI/CD, add a GitHub Actions workflow that builds the Docker image and pushes to your registry on every push to main. RapidDev can help configure the full CI/CD pipeline if you need GitHub Actions + container registry + deployment automation all connected.

1# Build the image
2# docker build -t my-v0-app .
3
4# Run with env file
5# docker run -p 3000:3000 --env-file .env.local my-v0-app
6
7# Check image size
8# docker images my-v0-app
9
10# Tag for Docker Hub
11# docker tag my-v0-app username/my-v0-app:v1.0.0
12# docker push username/my-v0-app:v1.0.0
13
14# Tag for Google Container Registry
15# docker tag my-v0-app gcr.io/your-project-id/my-v0-app:latest
16# docker push gcr.io/your-project-id/my-v0-app:latest