[DeployHQ](https://www.deployhq.com) launched [Static Hosting](https://www.deployhq.com/hosting/static) this year — a fully-managed home for static sites and Single Page Applications, served globally from Cloudflare's edge network. Connect your repository, point us at a build directory, and every push deploys to a hostname under `deployhq-sites.com`. No server to provision, no infrastructure to configure, no separate hosting account to manage.

This guide covers what [DeployHQ](https://www.deployhq.com) Static Hosting is, who it's for, how it compares to the alternatives (Vercel, Netlify, Cloudflare Pages), what it costs, and how to deploy your first site in under five minutes.

## What DeployHQ Static Hosting is

It's a managed static-site host built on Cloudflare's edge network. The same network the major static hosts use sits under the hood — we just add the deployment pipeline, framework auto-detection, atomic deploys, and the workflow tools you'd already use for the rest of your stack.

A static site here means anything that compiles down to HTML, CSS, JavaScript, and assets — no runtime server execution. Common cases:

- Marketing sites and documentation built with [Hugo](https://www.deployhq.com/guides/hugo), [Jekyll](https://www.deployhq.com/guides/jekyll), [Eleventy](https://www.deployhq.com/guides/eleventy), or [Astro](https://www.deployhq.com/guides/astro)
- Single Page Applications built with [React](https://www.deployhq.com/guides/react), [Vue](https://www.deployhq.com/guides/vue), or [Angular](https://www.deployhq.com/guides/angular)
- Statically-exported [Next.js](https://www.deployhq.com/guides/next) and [Nuxt](https://www.deployhq.com/guides/nuxt) apps
- Prerendered [SvelteKit](https://www.deployhq.com/guides/sveltekit) and [Remix](https://www.deployhq.com/guides/remix) sites
- Documentation sites built with [VuePress](https://www.deployhq.com/guides/vuepress), [Docusaurus](https://www.deployhq.com/guides/deploy-docusaurus), or similar

If your project builds to a folder of HTML/JS/CSS, [DeployHQ](https://www.deployhq.com) Static Hosting will serve it.

## Why DeployHQ Static Hosting

Most teams asking where should I host my static site end up choosing between Vercel, Netlify, Cloudflare Pages, or rolling their own with S3 + CloudFront. [DeployHQ](https://www.deployhq.com) Static Hosting overlaps with all of them on the basics — push to a repo, get a globally-distributed CDN. The differences are in what comes around the static-hosting part:

- **One workflow for static and dynamic.** The same [DeployHQ](https://www.deployhq.com) project that hosts your static frontend can also deploy your Laravel API to a VPS, your WordPress install to shared hosting, or your Node app to an EC2 instance. Vercel and Netlify only handle the static piece; you keep a separate tool and bill for the backend.
- **One bill.** The hosting cost rolls into your [DeployHQ](https://www.deployhq.com) subscription. No separate Vercel/Netlify invoice, no metered bandwidth surprises.
- **Cloudflare edge.** Every site is served from Cloudflare's global edge network — automatic HTTPS, DDoS protection, and the same latency profile as Cloudflare Pages.
- **Framework auto-detection.** When you connect a repository, [DeployHQ](https://www.deployhq.com) inspects `package.json` and the framework's config files (`next.config.js`, `vite.config.ts`, `_config.yml`, etc.) and pre-fills the build directory and SPA mode for you. The detection is advisory — you can override anything before clicking Create.
- **Atomic deploys.** Each build is uploaded in full to object storage before the edge routing flips. Users never see partial files or a half-deployed site during a transfer.
- **SPA mode.** For client-side-routed apps (React Router, Vue Router, and similar), unknown paths get rewritten to `/index.html` so the router can handle them — no special config needed.
- **Bring-your-own still works.** If you want to keep deploying to your own S3 bucket, Netlify account, or Vercel project, the same [DeployHQ](https://www.deployhq.com) project supports that side-by-side.

## How it works

Static Hosting is currently a beta feature. To enable it on your account, go to **Settings \> Beta Features** and turn it on. After that, it appears as a server type when you add a new server to any project.

### Provisioning a site

1. In your [DeployHQ](https://www.deployhq.com) project, click **New Server**.
2. Enter a name for the server (this is just for your reference — it doesn't affect the public URL).
3. Select **Static Hosting** from the protocol picker, under the **Hosting** section.
4. Choose a subdomain. Your site will be served at `<subdomain>.deployhq-sites.com`. Subdomains must be unique across all [DeployHQ](https://www.deployhq.com) accounts; lowercase letters, numbers, and hyphens only. You can rename it later (limit one rename per 24 hours).
5. Set the subdirectory to deploy from — the folder in your repository that contains your built site output. Common values: `dist` (Vite, Astro), `_site` (Jekyll), `build` (Create React App), `public` (Hugo, Eleventy), `.output/public` (Nuxt). Leave blank to deploy from the repository root.
6. Toggle **SPA mode** if your app uses client-side routing.
7. Click **Create Server**.

Provisioning usually takes under a minute. Once the status flips to active, push to your repository (or trigger a manual deployment) and [DeployHQ](https://www.deployhq.com) builds the site, uploads the build directory's contents to object storage, and updates the edge routing so the latest version is served immediately.

### Custom domains

You can map a custom domain (e.g., `docs.example.com`) to your Static Hosting site by adding a CNAME record at your DNS provider pointing to `<subdomain>.deployhq-sites.com`. HTTPS certificates are provisioned automatically by Cloudflare.

### Framework detection

When you connect a repository, the setup form pre-fills the subdirectory and SPA mode based on the framework we detect. A purple callout appears at the top of Site Configuration — for example, Next.js detected! with the recommended `dist` output directory.

Detection runs in two layers: a rule-based check against public manifest files (`package.json`, `next.config.js`, `vite.config.ts`, and similar), and an AI-assisted fallback for projects the rules cannot classify. Only the manifest files are read — never your application source code, environment files, or secrets. See the full file list and AI-fallback policy in [How](https://www.deployhq.com/support/repository-tech-detection)[DeployHQ](https://www.deployhq.com) detects your project's tech stack.

Detection is advisory. You can override any pre-filled value before clicking Create Server.

[Start a free](https://www.deployhq.com/signup)[DeployHQ](https://www.deployhq.com) trial to provision your first Static Hosting site — trial accounts get one site at no charge.

## How it compares to Vercel, Netlify, and Cloudflare Pages

The static-hosting category is well-served. None of these is bad. The right choice depends on what's around the static site in your stack.

| Capability | DeployHQ Static Hosting | Vercel | Netlify | Cloudflare Pages |
| --- | --- | --- | --- | --- |
| Edge network | Cloudflare | Vercel Edge | Netlify Edge | Cloudflare |
| Framework auto-detection | Yes (rule + AI fallback) | Best-in-class for Next.js | Yes | Yes |
| Atomic deploys | Yes | Yes | Yes | Yes |
| Server-side rendering | No (static only) | Yes | Yes | Limited (Workers) |
| Edge functions | No | Yes | Yes | Yes (Workers) |
| Same pipeline for backend deploys | Yes (VPS, shared host, cloud) | No | No | No |
| Pricing | Fixed monthly per site | Tiered + bandwidth | Tiered + bandwidth | Free for most uses |
| Beta status | Yes (mid-2026) | GA | GA | GA |

**Choose [DeployHQ](https://www.deployhq.com) Static Hosting if** you already use (or are evaluating) [DeployHQ](https://www.deployhq.com) for backend deploys, you want one workflow + one bill for the whole stack, you value pricing predictability over a free tier, and you don't need server-side rendering or edge functions.

**Choose Vercel if** you're building heavily with Next.js and depend on SSR, ISR, server components, or Vercel-specific features like deploy previews with comments. Vercel is the best Next.js platform; for Next.js-specific projects it's hard to beat.

**Choose Netlify if** you need built-in forms, identity, or split testing without bolting on a third-party service. Netlify pioneered the JAMstack model and has the most mature ecosystem of integrations.

**Choose Cloudflare Pages if** you're already deep in the Cloudflare ecosystem (Workers, R2, D1, KV) and want everything in one cloud account. Same edge network as [DeployHQ](https://www.deployhq.com) Static Hosting — the difference is whether you want DeployHQ's pipeline + multi-target deployment or Cloudflare's full platform.

For a broader comparison across the deployment-tool landscape (not just static hosting), see our roundup of [the best software deployment tools in 2026](https://www.deployhq.com/blog/best-software-deployment-tools).

## Pricing

Each active Static Hosting site is billed at a fixed monthly rate, shown on the Hosted Resources page in your account's currency and on each site's setup form. Pricing appears alongside your [DeployHQ](https://www.deployhq.com) plan on the same monthly invoice.

Suspended sites (e.g., during an account suspension) do not accrue charges. Sites removed mid-month are prorated to the day of removal.

Trial accounts can provision one Static Hosting site at no charge. Paid plans support additional sites.

## When Static Hosting isn't the right fit

Honest trade-offs — Static Hosting doesn't cover every use case:

- **Server-side rendering on every request.** Static Hosting serves prebuilt files. If your framework needs server-side rendering at request time (vanilla Next.js with `getServerSideProps`, full Nuxt, server-rendered SvelteKit), use [DeployHQ Managed VPS Hosting](https://www.deployhq.com/hosting/managed-vps) or your own VPS via [DeployHQ](https://www.deployhq.com) instead.
- **Backend APIs.** Static Hosting doesn't run server code. For an API to live alongside your frontend, deploy the API to Managed VPS or a BYO server in the same project — they coexist fine.
- **Database-backed apps.** Same reason. Static Hosting is for compiled assets; databases need a runtime.
- **Custom HTTP routing or middleware.** SPA mode handles client-side routing, but anything more complex (rewrites, custom headers, server-rendered redirects) needs edge functions, which Static Hosting doesn't currently support. Use Cloudflare Workers in front of your Static Hosting site, or move to a runtime that supports your middleware.

If you outgrow Static Hosting, the same [DeployHQ](https://www.deployhq.com) project supports a migration to Managed VPS or BYO server without rebuilding your pipeline — only the deployment target changes.

## Get started

1. Enable beta features under **Settings \> Beta Features** on your [DeployHQ](https://www.deployhq.com) account.
2. Open any project (or [create a new one](https://www.deployhq.com/signup) if you're new) and click **New Server**.
3. Pick **Static Hosting** , choose a subdomain, set the build directory, and create the site.
4. Push to your connected repository — [DeployHQ](https://www.deployhq.com) builds and deploys automatically.

Full provisioning, framework-detection, and management docs are at [Static Hosting in the support library](https://www.deployhq.com/support/servers/static-hosting). For background on where [DeployHQ](https://www.deployhq.com) Static Hosting fits among the five hosting types [DeployHQ](https://www.deployhq.com) 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 still on legacy shared hosting and wondering whether the move to managed static hosting makes sense, our guide on [shared hosting vs VPS for junior developers](https://www.deployhq.com/blog/shared-hosting-vs-vps-a-comprehensive-guide-for-junior-developers) walks through the trade-offs, and [5 signs it's time to upgrade from shared hosting to automated deployments](https://www.deployhq.com/blog/5-signs-it-s-time-to-upgrade-from-shared-hosting-to-automated-deployments) covers when the move becomes urgent. For the broader picture of why FTP-based shared hosting is the wrong default for new projects in 2026, [is FTP dead?](https://www.deployhq.com/blog/is-ftp-dead-a-look-at-its-continued-use-in-deployment) covers what to use instead.

* * *

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