Netlify

Status: 🟩 COMPLETE (🟦 LIVING — Netlify keeps shifting its product surface) Last updated: 2026-06-19 Plain-English tagline: A hosting platform with almost the same shape as Vercel — git-push deploys, global edge, serverless functions — but built around its own framework-agnostic philosophy rather than a single Next.js bias.

---

In plain English

Netlify is the original “Jamstack” hosting company, founded in 2014 — a year before Vercel. The pitch is essentially the same as Vercel’s: connect a Git repo, push code, watch your site deploy automatically to a global edge network with HTTPS, custom domains, environment variables, and serverless functions all included.

The differences that matter:

• Framework-agnostic by design. Vercel is the company that makes Next.js, so Next.js gets first-class treatment everywhere. Netlify supports Next.js too — but also Astro, Gatsby, Hugo, Eleventy, SvelteKit, Nuxt, Remix, Vue, and plain HTML with equal enthusiasm. If your stack isn’t React-centric, Netlify often feels more comfortable.

• A different center of gravity. Vercel optimizes for “the deployed Next.js webapp.” Netlify optimizes for “the deployed content site that may be one page or a million pages, in whatever framework.” Both are valid; the right one depends on your project.

• Pricing is similar but priced slightly differently. Free tier exists. Pro tier exists. Per-team-member pricing exists. The fine print differs (see below).

• Owned and operated by Netlify Inc., which acquired Gatsby in 2023, signaling a clear push to consolidate the framework-agnostic content-site market.

If Vercel + Next.js is the “default for React-centric webapps in 2026,” Netlify + Astro / Eleventy / Hugo / static is the “default for content-heavy and framework-flexible projects.”

---

Why it matters

Three reasons Netlify is worth knowing even if you default to Vercel:

1. It’s frequently the right answer for content sites. Marketing sites, blogs, documentation, brochure pages. Astro and Eleventy are excellent at these and Netlify is purpose-built for them.

2. The “Forms” feature is unique. Add a netlify attribute to an HTML <form> and Netlify automatically captures submissions, stores them, and notifies you — no backend required. Vercel has no built-in equivalent. For a contact form on a static site, this is a one-line solution.

3. Edge Functions on Deno. Netlify’s edge runtime is Deno-based (vs Vercel’s V8-based). For developers who already work in Deno, this is a more familiar environment with native TypeScript and Web standard APIs.

For Bible Quest specifically, Vercel is the right call because the stack is Next.js + Supabase and Vercel’s Next.js integration is unmatched. But the next project might be different.

---

How a Netlify deploy works

The flow looks nearly identical to Vercel:

git push origin main
       ↓
GitHub notifies Netlify
       ↓
Netlify spins up a build container
       ↓
Runs your build command (`npm run build`, `hugo`, `astro build`, etc.)
       ↓
Output (HTML, CSS, JS, images) uploaded to Netlify's edge
       ↓
Functions deployed separately to AWS Lambda (Functions) or to the Deno edge (Edge Functions)
       ↓
Live URL updates
       ↓
Old deploy still available at its permanent URL

Times are comparable: 60–180 seconds for a typical build. Like Vercel, Netlify keeps every deploy permanently (until you delete the site) and rollback is one click.

---

The four building blocks

Netlify exposes four primary products under the hood. Most projects use a subset:

1. Static Hosting

The original product. You upload (or build into) static files; Netlify serves them globally from edge CDNs. Caching, custom domains, SSL, redirects, headers — all included. For pure static sites, this alone is what you need.

2. Functions (serverless)

Run server code in response to HTTP requests, scheduled events, or background jobs. Built on AWS Lambda under the hood.

// netlify/functions/hello.js
export default async (req) => {
  return new Response("hello from netlify functions");
};

Auto-discovered at /.netlify/functions/hello.

3. Edge Functions

Lower-latency variant that runs on Deno at Netlify’s edge — close to users globally. Smaller bundle limits, restricted to Web APIs (no Node-specific modules), but much faster cold-start and closer to the visitor.

4. Identity / Forms / Analytics / Blobs

Netlify offers a handful of “batteries” you can opt into:

• Forms — auto-capture form submissions on static sites.
• Identity — user auth (GoTrue, the project that became Supabase Auth).
• Analytics — server-side analytics that work without JavaScript.
• Blobs — key-value storage at the edge.

These are convenient for solo developers but their maturity varies.

---

netlify.toml — configuration as code

Netlify’s equivalent of vercel.json is netlify.toml:

[build]
  command = "npm run build"
  publish = "dist"
  functions = "netlify/functions"
 
[build.environment]
  NODE_VERSION = "20"
 
[[redirects]]
  from = "/old-path"
  to = "/new-path"
  status = 301
 
[[headers]]
  for = "/*"
  [headers.values]
    X-Frame-Options = "DENY"
 
[functions]
  node_bundler = "esbuild"
 
[context.deploy-preview]
  command = "npm run build:preview"

The [context.*] blocks let you change settings per deploy context (production vs preview vs branch) — this pattern is more first-class in Netlify than in Vercel.

---

Deploy contexts — Netlify’s version of environments

Context	What it is
Production	Builds from your production branch (default: main)
Deploy Preview	Pull requests get their own URL — same idea as Vercel’s preview deploys
Branch Deploy	A persistent URL for any other branch (e.g. staging → staging--mysite.netlify.app)
Local Dev	netlify dev runs functions + redirects locally so things behave like production

Each context can have its own env vars, build command, and redirects. The [context.*] table in netlify.toml is the canonical place to define them in code.

---

A concrete example: deploying an Astro site

# 1. Build an Astro site locally
npm create astro@latest my-site
cd my-site
npm install
 
# 2. Push to GitHub
git init && git add -A && git commit -m "init"
gh repo create my-site --public --source=. --push
 
# 3. Connect on Netlify
# - Go to app.netlify.com → "Add new site" → "Import from Git"
# - Pick GitHub, pick the repo
# - Netlify auto-detects Astro and proposes:
#     Build command: npm run build
#     Publish dir:   dist
# - Click Deploy
 
# 4. Done. Live in ~90 seconds at `my-site.netlify.app`
# 5. Connect a domain in Site Settings → Domain Management

Identical shape to “deploy a Next.js site to Vercel.” The detail differs (publish dir, build command, edge function syntax), the rhythm is the same.

---

Pricing (as of mid-2026)

Tier	Cost	What you get
Starter (free)	$0	100GB bandwidth/month, 300 build minutes/month, 1 concurrent build, basic features. Commercial use IS allowed on the free tier (notable difference from Vercel Hobby).
Pro	$19/user/month	1TB bandwidth, more build minutes, custom domains, analytics
Enterprise	Custom	SOC 2, SAML SSO, dedicated support, higher limits

Big detail vs Vercel: Netlify allows commercial use on the free tier. Vercel Hobby strictly forbids it. For a side-project that might one day take money, Netlify Free is more forgiving.

The trade-off: Netlify’s bandwidth/build minute limits hit slightly earlier than Vercel’s equivalents for content-heavy sites. Run the numbers if you’re at the boundary.

---

Netlify vs Vercel — the honest comparison

Feature	Netlify	Vercel
Next.js support	Solid; deployment works	Excellent; native — every feature works
Astro / Hugo / Eleventy	First-class	Supported, less optimized
Edge runtime	Deno	V8 isolates / Node
Forms	Built-in (great for static sites)	Not provided
Identity / Auth	Built-in (basic)	Not provided
Image optimization	Netlify Image CDN ($)	Built-in & free for Next.js Image
Analytics	Server-side, paid	Built-in for Pro
Free tier commercial use	✅ Allowed	❌ Forbidden (Pro required)
Best for	Content sites, static + functions, framework-flexible	Next.js apps, dynamic webapps with React

Neither is universally better. The match between your framework and the platform’s strengths is what matters.

---

Common gotchas

• The build command must match your framework. Netlify auto-detects most frameworks correctly, but for monorepos or custom setups, you need to set the build command and publish directory manually. Check netlify.toml is the source of truth.

• publish directory is critical. For Next.js, it’s .next (with the Netlify Next.js Runtime). For Astro, dist. For Hugo, public. Wrong directory → “no files found” deploy.

• Next.js on Netlify uses an adapter. Netlify’s “Next.js Runtime” plugin handles SSR, ISR, and edge routes. Most Next.js features work, but the parity vs Vercel is close-but-not-identical, especially for the latest App Router edge cases. Check the runtime version against your Next.js version.

• Function size limits are smaller than you’d guess. AWS Lambda’s 50MB zipped limit applies — heavy dependencies (Puppeteer, headless Chrome) blow past this and need workarounds.

• Cold starts on Lambda Functions can be 500–2000ms. Edge Functions are much faster but have different constraints. Pick deliberately.

• Edge Functions are Deno-based. Most npm packages “just work” via Deno’s npm compat layer in 2026, but native Node-only modules can’t run. Stick to Web APIs and pure-JS libraries.

• Free tier build minutes can disappear fast. Each push triggers a build; each build costs minutes. A noisy repo (e.g. dependabot doing many small bumps) can chew through 300 minutes/month. Throttle or batch.

• Redirects are powerful but processed in order. A wildcard redirect early in netlify.toml can swallow more specific routes below. Order matters; test with netlify dev locally.

• _redirects and _headers files override netlify.toml. If you have both, the file-based version wins (legacy). Pick one source-of-truth approach per project.

• Deploy Preview URLs are public unless you enable password protection (Pro feature). Sensitive previews need explicit protection.

• Environment variables can be scoped per context. Production / Deploy Previews / Branch deploys can all have different values. Useful but easy to misconfigure — and to leak production keys into preview environments.

• The CLI (netlify) is essential for local function development. netlify dev boots a local server that mirrors production routing (redirects, functions, env vars). Running next dev alone won’t replicate Netlify’s behavior.

• Forms only capture submissions on STATIC sites (or after build). If you generate the HTML server-side (SSR Next.js), Netlify can’t see the netlify attribute on the form and Forms won’t activate. Stick to static contexts.

• Identity is being deprecated. Netlify Identity (the auth product) has been in maintenance mode. New projects should use Supabase Auth, Clerk, Auth0, or Cloudflare Workers Access instead — and Netlify itself recommends third-party auth now.

• Netlify Functions vs Next.js API Routes overlap. If you use Next.js on Netlify, you’ll typically use Next.js API routes (which Netlify wraps as functions for you). Adding standalone netlify/functions/* files alongside is legal but can confuse routing.

• Deploy log artifacts disappear after retention period. Free tier keeps build logs for a limited window. Don’t rely on Netlify as your archival debug log; capture important info elsewhere.

• Custom domains: www or apex, pick one. Netlify defaults to redirecting one to the other. Configure under Site Settings → Domain Management → set primary domain.

• The free tier’s 100GB/month bandwidth covers MANY sites. Don’t pre-optimize unless you’re hitting it. A typical content site uses 1–10GB/month.

---

When to pick Netlify over Vercel

• The project is Astro / Eleventy / Hugo / SvelteKit and Vercel has no specific edge over Netlify.
• The project is a static content site that needs Forms.
• The project might take money on the free tier (Vercel Hobby would forbid this).
• You want Deno at the edge specifically.
• You’re already on Netlify and there’s no reason to migrate.

When to pick Vercel over Netlify

• The project is Next.js, especially using the App Router and modern features (Server Actions, ISR, streaming).
• You want best-in-class image optimization with zero config.
• You’re investing in the v0 + Vercel AI SDK ecosystem.

When to pick neither

• The project is a long-running server (websockets, queue workers): use Render, Railway, or Fly.io.
• You need full OS control: a VPS.
• You’re already deep on Cloudflare and want Workers + Pages + R2 + D1 in one stack: use Cloudflare Pages.

---

See also

• Vercel 🟩 🟦 — the direct alternative
• Cloudflare 🟩 — third major contender, different shape
• What is hosting? 🟩
• Environment variables 🟩 — per-context vars
• CDNs 🟩 — both platforms run on global CDN backbones
• Domains and DNS 🟩
• HTTPS 🟩
• CD 🟩 — git-push deploys are CI/CD
• Regions & edge 🟩
• Glossary: Netlify, Jamstack, Serverless

---

Sources

• Netlify docs — canonical reference
• Netlify pricing
• Netlify Functions
• Netlify Edge Functions
• Netlify netlify.toml reference
• The State of JS — hosting — annual survey, includes hosting platform comparisons