Where to host your static site without paying for a second hosting plan
You built a site. Maybe you vibecoded it in Lovable, hand-rolled it in React, or generated it with Astro or Next.js. It looks great on localhost. Now comes the part nobody warns you about: getting it online, on a real domain, without signing up for yet another monthly bill.
This is the question we get asked most often, so let's answer it properly — not with a sales pitch, but with the actual trade-offs of each option. By the end you'll know which path fits your situation, including the one most people overlook: the hosting you're already paying for.
First, what "static" actually means
A static site is a folder of pre-built files — index.html, JavaScript, CSS, images. There's no database query or server-side rendering happening when someone visits. The server just hands over files.
That single fact is what makes static sites cheap and fast to host. Almost any web server can serve a folder of files, which means you have far more options than the hosting dashboard of your site builder wants you to believe.
The options, honestly compared
Here's the realistic landscape for a small-to-medium static site in 2026.
| Option | Typical cost | Custom domain | Best for | The catch |
|---|---|---|---|---|
| Builder-managed hosting (e.g. Lovable) | ~$20–25/mo | Yes | Fastest path, zero setup | Recurring bill for what is just file serving |
| Vercel / Netlify (free tier) | $0 to start | Yes | Devs who want CI/CD | Bandwidth/seat limits; costs jump on the paid tiers |
| Cloudflare / GitHub Pages | $0 | Yes | Hobby and docs sites | Fewer built-in features; some setup friction |
| Traditional WordPress / shared hosting | Already paid | Yes | Reusing what you own | Not designed for a modern build pipeline — until now |
There's no single "best" here. The right answer depends on what you already have and how much you want to spend.
When builder-managed hosting makes sense
If you value zero setup above everything and don't mind the subscription, the one-click hosting inside your builder is the path of least resistance. It just works. The downside is purely financial: you're paying $250–300 a year to serve a folder of files that hasn't changed since last week.
When Vercel or Netlify make sense
If you're comfortable with Git and want automatic deploys on every push, the free tiers are excellent — until you outgrow them. Watch the bandwidth caps, build-minute limits, and per-seat pricing. They're generous for a personal project and can get expensive for a small business.
The option almost everyone forgets
If you (or a client) already run a WordPress site, you're already paying for web hosting — a server whose entire job is to serve files over HTTP. That capacity is sitting there, mostly idle, every month.
The only reason people don't put their shiny new static site there is that traditional hosting wasn't built for a modern git push → build → deploy workflow. You'd be stuck dragging files over FTP like it's 2009.
That's the specific gap Parkstatic closes.
How static-on-WordPress works
The idea is simple: keep WordPress for administration and billing, but let it serve a static build to your visitors instead of rendering PHP on every request.
- You build your site in whatever tool you like.
- You push to GitHub.
- A GitHub Action builds the site and uploads the output to your WordPress install through the Parkstatic plugin.
- WordPress serves those static files from your existing domain and hosting.
Your visitors get a fast, fully static site. You get a real CI/CD pipeline. And you don't add a single new line item to your monthly costs.
The gotchas worth knowing before you commit
Serving a single-page app or a multi-route static site from any host — WordPress included — comes with a few sharp edges. None are dealbreakers, but knowing them up front saves an afternoon of debugging.
- Client-side routing needs a fallback. Apps built with React Router or TanStack Router handle routes in the browser. The server has to send
index.htmlfor unknown paths, or a deep link like/blog/my-postwill 404 on refresh. Good static-on-WordPress tooling handles this for you. - Asset paths matter in subdirectories. If WordPress lives in a subfolder, make sure your build uses the correct base path so CSS and JS resolve.
- Caching can hide your latest deploy. After a deploy, a stale cache may keep showing the old build. Test in a private window before assuming a deploy failed.
- Test your 404 behavior. Decide what a missing page should do, and confirm it actually does that in production.
A quick pre-launch checklist
Before you point your domain at any static deploy, run through this:
- The production build runs cleanly with no errors (
npm run buildor your equivalent). - Deep links work after a hard refresh, not just from the homepage.
- Images, fonts, and other assets load over HTTPS with no mixed-content warnings.
- Your 404 page behaves the way you intended.
- You've tested on mobile, not just your desktop browser.
So, which should you choose?
- You want zero setup and don't mind the bill → builder-managed hosting.
- You live in Git and your traffic is modest → Vercel or Netlify's free tier.
- You already pay for WordPress hosting → put your static site there and stop paying twice. That's exactly what Parkstatic was built for.
If that last one is you, the get started guide walks through the full setup — installing the plugin, connecting GitHub, and going live — in about ten minutes.