[DeployHQ Static Hosting](https://www.deployhq.com/hosting/static) 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](https://www.deployhq.com), 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](https://www.deployhq.com) 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](https://v0.app) — that you're happy with
- A GitHub account v0 can push to
- A [DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com) 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](https://www.deployhq.com) runs the same build.

## Step 3: Provision a Static Hosting site in DeployHQ

In your [DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com) 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](https://www.deployhq.com) 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](https://www.deployhq.com) runs your build before transferring artifacts to the edge. For a v0-exported Next.js project, the [build pipeline](https://www.deployhq.com/features/build-pipelines) 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](https://www.deployhq.com/signup) 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](https://www.deployhq.com) 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](https://www.deployhq.com) 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](https://www.deployhq.com).

## 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](https://www.deployhq.com) 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](https://www.deployhq.com/hosting). The [Static Hosting pillar guide](https://www.deployhq.com/blog/static-hosting-on-deployhq) covers framework auto-detection, SPA mode, and the head-to-head against the most common alternatives — including our [DeployHQ Static Hosting vs Vercel](https://www.deployhq.com/blog/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](https://www.deployhq.com/guides/next) 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](https://www.deployhq.com) project:

1. **Move to [DeployHQ Managed VPS](https://www.deployhq.com/hosting/managed-vps)** and run a full Next.js Node process. The [DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com) fits alongside the rest of the deployment-tool category, our [best software deployment tools in 2026](https://www.deployhq.com/blog/best-software-deployment-tools) post is a useful reference. And for context on the broader [DeployHQ](https://www.deployhq.com) proposition across all five hosting types it supports, see [your universal deployment and hosting platform](https://www.deployhq.com/blog/deployhq-your-universal-deployment-platform-for-all-hosting-types).

If you're sizing what's included before signing up, the [DeployHQ pricing page](https://www.deployhq.com/pricing) 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](https://www.deployhq.com/support/servers/static-hosting).

* * *

Questions or feedback on deploying v0 projects to [DeployHQ](https://www.deployhq.com) Static Hosting? Email [support@deployhq.com](mailto:support@deployhq.com) or follow [@deployhq](https://x.com/deployhq) on X for product updates.