Hosting / Deploy Decision Rule

Last updated: 2026-05-06

Honest Answer First

Use the lowest hosting layer that satisfies the job. Do not default every new web project to Netlify just because Netlify worked before.

The lawn co-op site proved the cheap fast lane: a plain static site in GitHub Pages, with Google Forms and WhatsApp handling the workflow, can be online quickly without Netlify or extra hosting fees.

The Command Center proves the app lane: login/database/PWA work is not just a "website." It needs a frontend host plus a backend/auth/data layer. Supabase can provide the backend, but the frontend can still live on Netlify, Cloudflare Pages, Vercel, or sometimes a static host.

Default Rule

Static public page only -> GitHub Pages first.
Static custom-domain site or PWA shell -> GitHub Pages or Cloudflare Pages first.
Static site with forms, redirects, previews, or quick agent deploys -> Netlify.
Next.js app with server behavior -> Netlify, Vercel, or Cloudflare Pages, chosen per project.
Login, database, file storage, realtime, or user-specific data -> Supabase for backend/auth, independent of frontend host.
Long-running jobs, queues, private APIs, or heavy backend logic -> do not force into a static host. Consider Supabase Edge Functions, Cloudflare Workers, Render, Fly, Railway, or a VPS after a real architecture check.

Current Examples In This Workspace

Project	Current path	What it teaches
Lawn co-op	GitHub Pages at `zee78900.github.io/north-woodmere-lawn-coop`	Best for public flyer pages, interest forms, and community initiatives. No Netlify needed.
LevSMS compliance site	Netlify static site at `levsms.com`	Good for quick custom domain, HTTPS, and Twilio compliance pages. Could also be GitHub Pages or Cloudflare Pages if Netlify access is blocked.
Hook Street Services	Netlify static/marketing site	Fine if using Netlify forms/previews/redirects. If it stays static, it can be moved to GitHub Pages or Cloudflare Pages.
Command Center	Next.js + Supabase + Netlify config	Real app lane. Supabase handles login/data; frontend host is replaceable if documented.

Platform Fit

Platform	Good for	Avoid when
GitHub Pages	Public static HTML/CSS/JS, simple project pages, emergency publishing, zero-fee fallback	Secrets, private data, server code, backend functions, sensitive transactions, complex auth flows
Cloudflare Pages	Static sites, custom domains, PWA shells, high-traffic static assets, cheap durable fallback, optional Workers	You need a simpler non-technical dashboard or Netlify-specific forms/features
Netlify	Static sites, deploy previews, custom domains, redirects, forms, functions, fast agent-driven deploys	A site is just a flyer and does not need the Netlify dependency, or account/billing access is unstable
Vercel	Next.js-first apps, strong framework support, polished previews	You want the cheapest default for many small commercial apps, or you do not need Next.js server behavior
Supabase	Postgres, Auth, Storage, Realtime, Edge Functions, API over data	Pure static websites, or projects that cannot tolerate database quotas/pausing without paid plan

The Key Distinction

PWA does not automatically mean Netlify. A PWA can be just static files: index.html, JS, CSS, manifest, service worker. That can run on GitHub Pages or Cloudflare Pages.

Login does not automatically mean Netlify either. Login means there is an auth/backend layer. Supabase can provide that while the frontend lives elsewhere. The security burden is then Supabase Row Level Security, environment variables, and data design, not the frontend host by itself.

Next.js server behavior is the real line. If the app relies on middleware, server actions, API routes, server rendering, or protected routes executed on the host, GitHub Pages is not enough unless the app is converted to a static client-side app.

Lockout / Cost Guardrails

For every public site or app, keep an escape hatch:

The domain stays in Sam-controlled Namecheap/Cloudflare/registrar DNS, not trapped inside the host.
The repo includes a README with build command, publish directory, current host, DNS records, and env var names.
No secrets are committed. .env.local stays local and ignored.
If using Supabase, commit schema/migrations but never service-role keys.
If using Netlify/Vercel/Cloudflare functions, document what would break if moved.
Prefer external low-risk tools for early validation: Google Forms, Airtable, Sheets, WhatsApp, email forwarding.
Use billing alerts/spend caps where available.
Before moving beyond static hosting, name the exact feature that requires it.

Decision Checklist

Ask these before choosing a host:

Is this public-only, with no user-specific data?
Is there any secret key or server-only credential?
Is there a login?
Is the login protecting real data or just gating a simple page?
Does it need server-side rendering, API routes, functions, scheduled jobs, webhooks, or email sending?
Could Google Forms/Sheets/WhatsApp handle the workflow for the first version?
If the host account is unavailable for two weeks, can another agent redeploy it from GitHub in under 30 minutes?

Done State

A hosting choice is done when the project has:

Chosen host and why.
Fallback host.
Domain/DNS records documented.
Build/deploy command documented.
Env var names documented without values.
Cost trigger documented: what usage or feature forces a paid tier.

Source Trail

GitHub Pages docs: static hosting from a repo, custom domains, HTTPS, and limits: https://docs.github.com/en/pages
Netlify pricing: free plan uses credits and includes custom domains with SSL, previews, functions, and related deploy features: https://www.netlify.com/pricing/
Cloudflare Pages docs: free plan supports static sites, custom domains, many builds, and optional Pages Functions/Workers: https://developers.cloudflare.com/pages/
Supabase docs: Free/Pro project limits, Auth/database/storage/egress quotas, Edge Function quotas, and compute billing: https://supabase.com/docs/guides/platform/billing-on-supabase
Vercel pricing/docs: strong Next.js hosting with free/pro tiers and usage-based billing: https://vercel.com/pricing