How to Deploy a Bolt App to DeployHQ Static Hosting

DeployHQ Static Hosting 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, 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 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 — that you're happy with
• A GitHub account Bolt 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 Bolt project to GitHub

Bolt runs your project inside a StackBlitz WebContainer in the browser. To deploy it on DeployHQ, 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.

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 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 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 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 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 runs your build before transferring artifacts to the edge. For a Bolt-exported project, the build pipeline 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 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 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 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

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 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. 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 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. Since Bolt ships with a one-click Netlify deploy button, the 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 project:

1. Move to DeployHQ Managed VPS and run the full Node app — both your frontend bundle and your server/ code in one place. The DeployHQ 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 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 Bolt projects to DeployHQ Static Hosting? Email support@deployhq.com or follow @deployhq on X for product updates.