[DeployHQ Static Hosting](https://www.deployhq.com/hosting/static) serves pre-built static assets from Cloudflare's global edge — exactly what a Bolt.new project produces when its frontend compiles. This guide walks through deploying a Bolt app end to end: export the project to GitHub, sanity-check the build output, provision the site in [DeployHQ](https://www.deployhq.com), configure the build pipeline, and ship the first deploy.

This is the _static frontend_ path. Bolt starter templates often ship with a `server/` directory running Express, Hono, or Fastify to handle data and auth — that code needs a Node runtime Static Hosting doesn't provide. If your Bolt app has a server, you have two clean options: run only the static frontend on Static Hosting and point it at your existing API, or use DeployHQ's Managed VPS option to host both the frontend and the Node server in one place. For purely client-side Bolt apps — landing pages, marketing sites, design demos, internal tools, prototypes, anything that talks to third-party APIs from the browser — Static Hosting is the cleanest fit.

## What you'll build

By the end of this guide:

- A Bolt.new 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 your framework's build command 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 Bolt project you already have generated.

## Prerequisites

- A Bolt.new project — generated at [bolt.new](https://bolt.new) — that you're happy with
- A GitHub account Bolt 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 Bolt project to GitHub

Bolt runs your project inside a StackBlitz WebContainer in the browser. To deploy it on [DeployHQ](https://www.deployhq.com), the code needs to live in a normal Git repository.

In Bolt:

1. Open the project you want to deploy
2. Click the **GitHub** icon in the top toolbar (or **Export** depending on your Bolt version)
3. Authorize Bolt to access your GitHub account if you haven't already
4. Choose a repository name and visibility, then push

Bolt commits the full project — `package.json`, framework config files, `src/`, `public/`, and any `.bolt/` metadata directory — to the `main` branch of the new repository.

Open the repo in GitHub and confirm `package.json` is at the root. You'll use it to identify the build command and output directory in the next step.

## Step 2: Identify the framework and output directory

Bolt projects are framework-agnostic. The right Static Hosting configuration depends on which framework Bolt scaffolded for you. The build output directory is what matters — Static Hosting uploads the contents of that directory to the edge.

| Framework | Default build command | Output directory |
| --- | --- | --- |
| Vite + React | `npm run build` | `dist/` |
| Vite + Vue | `npm run build` | `dist/` |
| Vite + Svelte | `npm run build` | `dist/` |
| Astro | `npm run build` | `dist/` |
| SvelteKit (adapter-static) | `npm run build` | `build/` |
| Next.js (static export) | `npm run build` | `out/` |
| Remix (with static adapter) | `npm run build` | `build/client/` |

Open `package.json` and confirm the `build` script matches what's in the table. Open the framework config (e.g., `vite.config.ts`, `astro.config.mjs`, `next.config.js`) and note any custom output directory if it's been overridden.

If your Bolt project is a Next.js starter, ensure `output: 'export'` is set in `next.config.js` — Bolt's default Next.js scaffold assumes a Node runtime. The [Next.js deployment guide](https://www.deployhq.com/guides/next) covers the full static-export configuration.

If your project includes a `server/` directory (Express, Hono, Fastify, etc.), that code won't run on Static Hosting — make sure none of your frontend code depends on those endpoints at runtime, or refactor those calls to hit a separate API.

## 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 Bolt 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 match your framework's output directory from Step 2 (`dist/`, `out/`, `build/`, or `build/client/`)
5. Toggle **SPA mode** based on your framework:
  - **On** for Vite + React SPA, Vite + Vue SPA, Vite + Svelte SPA — these single HTML files use client-side routing and need unknown paths rewritten to `index.html`
  - **Off** for Astro, SvelteKit static, and Next.js static export — these generate one HTML file per route at build time

6. Click **Create Server**

[DeployHQ](https://www.deployhq.com) runs framework detection against the connected repository. If a [Framework] detected! callout appears with a suggested output directory and SPA mode, the rule-based detector is doing the work for you. Accept the suggested values unless you have a non-default config.

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 Bolt-exported 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 your `package.json` declares `pnpm` or `yarn` as the package manager (Bolt sometimes does, especially for monorepo-style starters), swap to `pnpm install --frozen-lockfile` or `yarn install --frozen-lockfile`.

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

- Public-prefixed env vars your framework inlines into the static bundle (Vite: `VITE_*`, Next.js: `NEXT_PUBLIC_*`, Astro: `PUBLIC_*`)
- `NODE_ENV=production` — usually set automatically but worth confirming for deterministic builds

Anything that isn't prefixed for client exposure stays out of the bundle — that's the framework's standard behavior, not a Static Hosting limitation. If your Bolt project talks to Supabase, Stripe (publishable key), or a third-party API, the URLs and public keys go here. Service-role keys, secret API tokens, and database credentials never belong in a static build.

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 your output directory 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 Bolt-exported projects:

- A starter template that includes a `server/` directory the frontend code depends on at build time
- Hardcoded paths starting with `/home/project/` left over from the WebContainer environment
- A missing dependency the `package.json` declares but Bolt didn't ship a lockfile entry for
- Framework-specific config overrides (custom `outDir`, `base`, or `publicPath`) the build pipeline doesn't know about

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

**The build pulls in `server/` files.** Bolt full-stack starter templates expect the server and client to coexist. If your `vite.config.ts` or framework config includes a path alias pointing into `server/`, the build will try to bundle Node-only modules and fail. Either remove the alias for a pure frontend deployment, or move the server to [DeployHQ](https://www.deployhq.com) Managed VPS.

**Hardcoded WebContainer paths.** Bolt sometimes leaves `/home/project/` paths in generated code, especially in scripts or test fixtures. These break in any environment that isn't a WebContainer. Search the repo for `/home/project/` and replace with relative paths or `process.cwd()`.

**Build succeeds but the page is blank.** Vite + React SPAs often need `base: '/'` set explicitly in `vite.config.ts` when deployed at the root. If you're deploying under a subpath, set `base: '/subpath/'` to match. Check the browser console — a 404 on `/assets/index-*.js` is the giveaway.

**Tailwind classes missing in production.** Bolt's Vite scaffold sometimes uses content paths that miss files in nested directories. Verify `tailwind.config.ts` includes every path your components actually live under — `./src/**/*.{js,ts,jsx,tsx,vue,svelte}` covers the standard layout, but Bolt's project structure can vary.

**Routes 404 on direct page load (Vite SPA).** This is SPA mode not being enabled in [DeployHQ](https://www.deployhq.com). Toggle it on — Static Hosting will rewrite unknown paths to `index.html` so client-side routing takes over.

**Supabase auth callback fails.** If your Bolt app uses Supabase and the auth callback URL points to a `/auth/callback` route handler, it'll 404 because that route handler can't run on Static Hosting. Move the auth-callback logic into client-side code that reads the URL hash, or run the callback handler on a separate backend.

## What you've shipped

You now have:

- A Bolt 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. Since Bolt ships with a one-click Netlify deploy button, the [DeployHQ Static Hosting vs Netlify](https://www.deployhq.com/blog/deployhq-static-hosting-vs-netlify) comparison is directly relevant when you're choosing where to host outside the built-in option.

## What's next

If your Bolt project outgrows static export — you need to run the `server/` directory in production, add real auth, or handle dynamic data without a separate backend — 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 the full Node app — both your frontend bundle and your `server/` code in one place. The [DeployHQ](https://www.deployhq.com) pipeline ships to either target; you swap the server type, not the project.
2. **Split: keep Static Hosting for the UI, run the `server/` directory elsewhere.** A separate Managed VPS or BYO server hosts the API, and the static frontend stays on Cloudflare's edge.

Either path, the build pipeline you set up here continues to work — DeployHQ's build is generic, the target is what swaps.

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 Bolt 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.