How to Deploy a v0 App to DeployHQ Static Hosting

By Alex M · Posted on

AI, Devops & Infrastructure, Frontend, and Tutorials

How to Deploy a v0 App to DeployHQ Static Hosting

DeployHQ Static Hosting runs static builds on Cloudflare's global edge — exactly the shape v0 produces when you export a project as a Next.js codebase. This guide walks through deploying a v0 app end to end: export the project to GitHub, provision the site in DeployHQ, configure the build pipeline, and ship the first deploy.

This is the static-export path. If your v0 project uses Next.js server actions, App Router server components, or any backend route handlers, Static Hosting can't run that code — those parts need a Node runtime on DeployHQ's Managed VPS option, a separate serverless layer, or an existing API you call from the client. For purely static UI — marketing pages, landing pages, design demos, internal tools, prototypes — Static Hosting is the cleanest fit.

What you'll build

By the end of this guide:

  • A v0 project exported to your own GitHub repository
  • A DeployHQ project with Static Hosting connected to that repo
  • A working build pipeline that runs next build (with static export) and uploads the output to Cloudflare's edge
  • The site serving over HTTPS at <subdomain>.deployhq-sites.com (and optionally a custom domain)
  • Atomic deploys on every push to main, with one-click rollback to any previous version

Expected time: under 15 minutes from a v0 project you already have generated.

Prerequisites

  • A v0 project — generated at v0.app — that you're happy with
  • A GitHub account v0 can push to
  • A DeployHQ account with beta features enabled (enable under Settings > Beta Features)
  • Node.js installed locally if you want to test the build before pushing (optional but recommended)

If you don't have a DeployHQ account yet, you can start a free trial in the next step — the trial includes one Static Hosting site at no charge while the feature is in beta.

Step 1: Export your v0 project to GitHub

v0 generates Next.js code. To deploy it anywhere outside v0's built-in Vercel target, you need the code in your own repository.

In v0:

  1. Open the project you want to deploy
  2. Click the GitHub icon in the project toolbar (or Export → GitHub depending on your v0 version)
  3. Authorize v0 to access your GitHub account if you haven't already
  4. Choose Create new repository and pick a name, or Push to existing repository if you've already exported once
  5. Confirm the push

v0 commits the full Next.js project — app/, components/, package.json, next.config.js, tailwind.config.ts, and the rest — to the main branch of the repository you selected.

Open the repo in GitHub and confirm next.config.js (or next.config.mjs) is present. You'll edit it in the next step.

Step 2: Configure Next.js for static export

v0's generated next.config.js is set up for Vercel by default, which assumes a Node runtime. Static Hosting needs the export build instead.

Edit next.config.js to add output: 'export' and disable Next.js Image Optimization (it requires a server):

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'export',
  images: {
    unoptimized: true,
  },
};

module.exports = nextConfig;

A few things this changes:

  • next build writes a static export to out/ instead of starting a Node server
  • Any route using getServerSideProps, server actions, route handlers, or middleware will fail the build — those features need a runtime Static Hosting doesn't provide
  • next/image falls back to plain <img> rendering — no on-the-fly resizing

Commit and push the change:

git add next.config.js
git commit -m "Configure Next.js for static export"
git push origin main

Optionally, run npm install && npm run build locally first to catch any server-only code paths v0 emitted before DeployHQ runs the same build.

Step 3: Provision a Static Hosting site in DeployHQ

In your DeployHQ project (or create one and connect it to the v0 repository), click New Server:

  1. Enter a name for the server — internal reference only, doesn't affect the public URL
  2. Select Static Hosting from the protocol picker under Hosting
  3. Choose a subdomain — your site serves at <subdomain>.deployhq-sites.com. Subdomains are unique across all DeployHQ accounts; lowercase letters, numbers, and hyphens only
  4. Set the subdirectory to deploy from to out (the default Next.js static export directory)
  5. Leave SPA mode off — Next.js static export generates one HTML file per route, so client-side routing fallbacks aren't needed
  6. Click Create Server

DeployHQ runs framework detection against the connected repository. If a Next.js detected! callout appears, the rule-based detector picked up your next.config.js. Accept the suggested values for a stock v0 export.

Provisioning takes under a minute. Once the status flips to active, the site exists on Cloudflare's edge — but no code has shipped yet.

Step 4: Configure the build pipeline

DeployHQ runs your build before transferring artifacts to the edge. For a v0-exported Next.js project, the build pipeline needs two stages: install, then build.

In the project's build settings, add:

npm ci
npm run build

If v0 emitted a pnpm-lock.yaml or yarn.lock instead of package-lock.json, swap to pnpm install --frozen-lockfile or yarn install --frozen-lockfile accordingly.

Environment variables to set in DeployHQ's environment-variable UI:

  • NEXT_PUBLIC_* — any public env vars Next.js inlines into the static bundle (API base URLs, public keys, feature flags)
  • NODE_ENV=production — usually set automatically but worth confirming for deterministic builds

Anything not prefixed with NEXT_PUBLIC_ will not appear in the static bundle — that's Next.js's standard behavior, not a Static Hosting quirk.

If your v0 project hits external APIs (Supabase for auth, a database backend, third-party services), the URLs and public keys go here. Secrets that should never reach the client — service-role keys, private API tokens — stay out of the static build entirely.

Ready to take it live? Sign up free for DeployHQ if you don't have an account, and the beta-tier Static Hosting site is enough to ship this guide end to end.

Step 5: First deploy

Push any change to the configured branch (typically main), or trigger a manual deployment from the DeployHQ dashboard. DeployHQ:

  1. Clones the repo at the head of the configured branch
  2. Runs the build pipeline (npm ci && npm run build)
  3. Uploads the contents of out/ to object storage atomically
  4. Flips Cloudflare's edge routing to serve the new version

The deployment log streams each step in real time. When it completes, visit https://<subdomain>.deployhq-sites.com and confirm the site renders.

If the build fails, the log shows the exact error. Most common failures for v0 exports:

  • A page or route handler v0 generated that uses a server-only feature (server actions, getServerSideProps)
  • next/image used without unoptimized: true
  • A missing dependency v0's package.json declares but didn't ship with a lockfile entry

Fix the issue in the repo, commit, push — DeployHQ runs the next build automatically.

Step 6: Add a custom domain

To serve from your own domain (e.g., app.example.com):

  1. In your DNS provider, add a CNAME record pointing your subdomain to <subdomain>.deployhq-sites.com
  2. Wait for DNS propagation (usually minutes; depends on your TTL)
  3. Cloudflare provisions an HTTPS certificate automatically once the CNAME resolves

Your site now serves from app.example.com over HTTPS via Cloudflare's edge.

For an apex domain (example.com with no subdomain), use an ALIAS or ANAME record if your DNS provider supports them — Cloudflare DNS, DNSimple, and Route 53 all do. Otherwise, host the apex elsewhere and CNAME a www subdomain to DeployHQ.

Common gotchas

Server actions fail at build. v0 sometimes generates form submissions as server actions. Static export can't run server code at request time, so those builds break. Refactor server actions into client-side fetches that hit a separate API (your existing backend, a Cloudflare Worker, Supabase, etc.).

Route handlers (app/api/*) don't work. Same root cause — they need a Node runtime. Move that logic to a separate backend, or call third-party APIs directly from the client when the keys are public.

Images render but look unoptimized. next/image skips its optimization pipeline under unoptimized: true. For better performance, pre-optimize at build time with sharp or next-export-optimize-images, or use an image CDN (Cloudflare Images, Imgix, Cloudinary).

Build succeeds but routes 404 on the live site. v0 dynamic routes ([slug].tsx) need generateStaticParams to enumerate which paths to render at build time. Without that, the export skips the dynamic routes entirely. Add generateStaticParams returning the list of slugs you want pre-rendered.

Tailwind classes missing in production. v0 occasionally generates class names that Tailwind's content scanner misses. Double-check tailwind.config.ts includes every path your components live under — ./app/**/*.{js,ts,jsx,tsx,mdx} and ./components/**/*.{js,ts,jsx,tsx,mdx} cover most v0 projects.

Trailing slashes change URLs mid-project. If you add trailingSlash: true to next.config.js after the first deploy, every route URL changes. Set it intentionally at the start, or commit to a redirect plan if you switch.

What you've shipped

You now have:

  • A v0 project rebuilding on every push to main
  • Atomic deploys with no downtime during the transfer
  • HTTPS over Cloudflare's edge with automatic certificate management
  • One-click rollback to any previous deployment from the DeployHQ dashboard
  • Predictable, free hosting while Static Hosting is in beta

For the broader context of how Static Hosting fits among DeployHQ's other hosting types, see the hosting hub. The Static Hosting pillar guide covers framework auto-detection, SPA mode, and the head-to-head against the most common alternatives — including our DeployHQ Static Hosting vs Vercel comparison, which is directly relevant for v0 users weighing where to host outside Vercel itself.

For the full Next.js side of the workflow, the Next.js deployment guide goes deeper on configuration choices that apply equally to v0-exported projects.

What's next

If your v0 project outgrows static export — you add real auth, dynamic data, or server actions you can't refactor away — there are two clean upgrade paths inside the same DeployHQ project:

  1. Move to DeployHQ Managed VPS and run a full Next.js Node process. The DeployHQ pipeline you built ships to either target; you swap the server type, not the project.
  2. Split: keep Static Hosting for the UI, run dynamic parts elsewhere. A separate Managed VPS or BYO server handles the API/SSR, and the static frontend stays on Cloudflare's edge.

Either path, the build pipeline you set up here doesn't change.

For a roundup of how DeployHQ fits alongside the rest of the deployment-tool category, our best software deployment tools in 2026 post is a useful reference. And for context on the broader DeployHQ proposition across all five hosting types it supports, see your universal deployment and hosting platform.

If you're sizing what's included before signing up, the DeployHQ pricing page lays out which plan covers what — the beta-tier Static Hosting site is enough to ship this guide end to end. For the full product reference, see the Static Hosting support library.

Questions or feedback on deploying v0 projects to DeployHQ Static Hosting? Email support@deployhq.com or follow @deployhq on X for product updates.