All posts
DevOps 2 min read

Static-first: shipping a Next.js site on shared hosting

Most tutorials assume you deploy Next.js to a serverless platform. But a huge part of the web still lives on shared hosting — and that's perfectly fine. With output: "export", Next.js compiles the whole app into plain HTML, CSS and JavaScript that Apache can serve without breaking a sweat.

Why bother?

  • Cost — you're already paying for the hosting.
  • Simplicity — no cold starts, no runtime to patch, no vendor lock-in.
  • Speed — static files behind Cloudflare are about as fast as it gets.

The setup

The trick is to move the build step into CI. My pipeline does three things on every push to main:

  1. npm ci && npm run build — produces the out/ folder.
  2. Commits out/ to a dedicated deploy branch.
  3. Calls the cPanel API to pull that branch and rsync it into public_html.
- run: npm run build
- run: |
    git worktree add ../deploy origin/deploy
    rsync -a --delete out/ ../deploy/
    cd ../deploy && git add -A && git commit -m "deploy" && git push

The server never runs Node. It just receives files — which is exactly what shared hosting is good at.

What you give up

Server components still work (they render at build time), but anything truly dynamic — API routes, ISR, middleware — is off the table. For a portfolio or a marketing site that trade-off is usually free: the content changes when you push, and that's the moment it rebuilds anyway.

Static-first isn't a compromise. For most sites it's the correct default.

Next.jscPanelCI/CDPerformance