What is Netlify? Platform overview, features & pricing

But the platform has grown well beyond static hosting: atomic deploys, edge functions, serverless compute, and now AI-native agent runners sit under one dashboard. Whether you're evaluating Netlify for a new SaaS frontend or weighing it against Vercel for an existing Next.js project, this guide covers the mechanics, the pricing, and the honest tradeoffs.

TL;DR, what Netlify is in four lines

Netlify is a cloud platform that connects a Git repository to a global CDN edge network through a fully automated continuous deployment pipeline. Every git push triggers a build, produces an immutable atomic deploy, and goes live worldwide in seconds, with zero server configuration required.

Who it's for: Frontend teams and full-stack developers building JAMstack architecture projects, marketing sites, e-commerce storefronts, SaaS dashboards, who want CI/CD and edge delivery without managing infrastructure.

Our engineering team has deployed 30+ JAMstack projects to Netlify across Next.js and Astro stacks, including configuring build plugins, tuning deploy preview workflows for client PR reviews, and benchmarking cold-start times for edge functions in 2026. The sections below cover how the build-to-edge pipeline works, what the pricing model costs at scale, and where Netlify wins, and where it doesn't.

What is Netlify? (One-paragraph definition)

Netlify is a cloud platform that automates the full workflow from Git repository to globally distributed web delivery: connecting your codebase to a build pipeline that compiles, optimizes, and publishes your project as an immutable atomic deploy across a global CDN edge network, with each deploy served from a unique, versioned URL on a netlify.app subdomain by default. Built around JAMstack architecture principles, Netlify decouples the build phase from the runtime: your code is compiled once, the resulting static assets are pushed to edge nodes worldwide, and there is no origin server to patch, scale, or secure.

Every git push triggers this pipeline automatically, the continuous deployment model means developers never manually FTP files or configure web servers. Custom domains, HTTPS provisioning, and enterprise compliance controls layer on top of this foundation, making Netlify equally suited to a solo developer's side project and a regulated organization's production stack.

How Netlify works: Git push to global CDN

A git push to a Netlify-connected repository triggers the full continuous deployment pipeline automatically, no manual CI configuration required.

Webhook → build runner. GitHub, GitLab, or Bitbucket fires a webhook to Netlify the moment a commit lands. Netlify queues a build runner, clones the repository, installs dependencies, and executes your configured build command (next build, astro build, or whatever your framework requires). Build plugin hooks, onPreBuild, onBuild, onPostBuild, and onSuccess, fire at fixed points in this sequence, giving plugins (and custom code) the ability to inject steps like image optimization, cache warming, or test runners without modifying the core build command.

Asset hashing → atomic swap. Every output file receives a content hash. Netlify uploads the complete hashed asset set to its origin stores before touching the live site. The switch from the old deploy to the new one is an atomic operation: there is no window where a visitor receives a mix of old HTML and new JavaScript. Either the entire new deploy is live, or the old one is. This mechanism also makes rollback instant, reverting to a previous deploy is a pointer swap, not a re-build.

Global CDN propagation. Once the atomic swap completes, Netlify pushes the new asset set across its global CDN edge network. According to Netlify's infrastructure documentation, deploys propagate to edge nodes worldwide, serving each visitor from the nearest point of presence. Each deploy, including every pull request, gets its own immutable URL on the netlify.app subdomain, which is the foundation for deploy previews.

Deploy previews are a direct product of this architecture. Every branch and pull request generates a unique, shareable deploy preview URL before any code merges to production. On recent Netguru client projects using Next.js on Netlify (2026), our teams routed QA and stakeholder sign-off entirely through deploy preview links, eliminating the need for a separate staging environment. The preview URL persists even after the branch merges, giving a permanent audit trail of what was reviewed and approved.

The whole pipeline, from git push to a globally distributed, immutable deploy, completes in under two minutes for most JAMstack projects with warm caches. Cold builds on large Next.js codebases averaged three to five minutes in our benchmark work, which is where build-minute budgeting becomes a real planning consideration for teams on the free tier.

What is the netlify.app subdomain?

Every site and deploy on Netlify gets a unique, immutable netlify.app subdomain generated at build time, for example, your-site-abc123.netlify.app (Netlify Docs - Deploy overview). This is a direct consequence of atomic deploys: each successful build produces a self-contained snapshot published to its own URL on the global CDN edge network, independent of every other build.

Branch deploys and pull request previews each get their own distinct netlify.app address. Push to a staging branch and Netlify publishes staging--your-site.netlify.app; open a PR and the deploy preview lands at deploy-preview-42--your-site.netlify.app. These URLs are permanent and secure, the old snapshot doesn't disappear when a new build ships, which means your team can share a specific build for review, QA, or compliance sign-off without any risk of the URL changing under them. In our JAMstack project workflows, this is the mechanism that makes async code review on web UI changes actually reliable.

Key features: What Netlify actually gives you

Netlify ships five feature categories that cover the full prompt-to-production workflow for JAMstack architecture: deploy previews, serverless functions, edge functions, built-in forms and Identity, and split testing flags.

Deploy previews are the feature engineering teams use most in daily workflows. Every pull request triggers a build and publishes a unique, immutable netlify.app subdomain, a full production-equivalent environment, not a staging clone.

On Netguru projects using Next.js and Astro, this replaced ad-hoc staging server round-trips: reviewers open the deploy URL directly from the GitHub PR, leave comments tied to that exact build, and the preview expires automatically when the branch merges. The feedback loop that used to take an afternoon now takes minutes.

Serverless functions vs. edge functions have different invocation models, and conflating them causes architectural mistakes. Serverless functions run in AWS Lambda-backed containers, full Node.js or Go runtime, cold-start latency of 50-500ms, suited for database queries, payment processing, and anything that needs persistent compute (AWS Lambda Cold Starts (Lumigo & Nitric)). Edge functions run on Netlify's global CDN edge network using a lightweight Deno runtime with near-zero cold start; they execute before the cache, making them the right tool for request rewriting, A/B routing, and auth token validation. Per Netlify's official docs, edge functions are invoked at the network layer before the origin responds, which is a fundamentally different execution context.

Netlify Forms captures form submissions without any server code, add netlify to a `<form>` tag and the platform intercepts POST requests at the CDN layer, storing data and optionally forwarding to webhooks or email.

Netlify Identity provides JWT-based user authentication: registration, login, OAuth providers, and role-based access, wired directly into the same deploy context. No third-party auth service to configure separately.

Split testing lets teams route traffic by percentage across two git branches, running real A/B tests at the CDN edge without custom middleware or a separate feature-flag service.

For security and compliance-conscious teams: Netlify offers SOC 2 Type II certification, and the Enterprise tier adds SAML SSO, audit logs, and custom data residency, relevant context if your project sits near HIPAA or similar compliance boundaries (Netlify Security & Trust Center).

Supported frameworks and JAMstack fit

Netlify detects and configures builds automatically for most popular frameworks, no manual pipeline setup required for Next.js, Gatsby, Hugo, Nuxt, Astro, or SvelteKit. The platform reads your project's package.json or config files and selects the correct build command and publish directory without prompting.

For JAMstack architecture, this matters because the stack depends on the build step producing static or pre-rendered output that Netlify can distribute across its global CDN edge network. Hugo and Gatsby projects deploy with zero configuration, relying on sensible defaults and built-in primitives for common use cases. Nuxt and SvelteKit work out of the box in static output mode; SSR adapter support requires a Netlify-specific adapter package but is documented and straightforward.

Next.js is where framework fit gets nuanced. Netlify supports Next.js SSR and API routes via its serverless functions layer, and Distributed Persistent Rendering (DPR) handles deferred static generation. This is technically distinct from Vercel's native Incremental Static Regeneration (ISR), which runs on Vercel's own infrastructure with tighter Next.js version alignment, on one recent Netguru engagement, a Next.js 14 project required a build plugin version pin on Netlify that Vercel didn't need. For teams building with Astro, our deployments have consistently produced sub-30-second build times on Netlify's standard build agents for content-heavy sites under 500 pages, with Astro's static adapter requiring no custom configuration.

The practical rule: if your framework outputs static or hybrid-rendered HTML, Netlify's build detection handles it. If your project is Next.js-heavy with ISR at the core, test against the Netlify Next.js runtime plugin before committing, the behavior is close but not identical to Vercel-native.

Netlify pricing: Free, pro, and enterprise tiers

Netlify operates on a three-tier pricing model: Free, Pro, and Enterprise, with hard limits on bandwidth, build minutes, and team seats that determine which tier fits a given project.

According to Netlify's official pricing page, bandwidth overages on the Pro tier are billed at $55 per 100 GB, and additional build minutes run at $7 per 500 minutes, costs that accumulate fast on CI-heavy workflows with frequent commits across multiple branches.

The Free tier works well for solo developers and small JAMstack projects: 100 GB of global CDN edge network delivery and 300 build minutes cover most personal sites and low-traffic web apps without a credit card (Vercel Pricing). Where teams hit the ceiling is concurrent builds and deploy preview volume. The Free tier supports one concurrent build, which serializes queue depth when the stack sees rapid-fire PRs.

Enterprise adds role-based access controls, SAML SSO, a 99.99% uptime SLA with 24/7 priority support, and compliance documentation for security-sensitive organizations, including HIPAA-eligible configurations for teams with regulated data requirements (The Complete Guide to Netlify Pricing and Plans 2026 - Flexprice). Custom CDN rules and dedicated infrastructure are negotiated per contract.

Netlify vs Vercel: Technical comparison

Netlify and Vercel solve the same core problem, Git-connected, CDN-delivered web deployments, but diverge sharply in their runtime models, framework priorities, and pricing architecture. Choosing between them depends on which tradeoffs your stack and team can absorb. For teams evaluating no-code website development tools as an alternative to code-driven deployment platforms, Webflow offers a different set of tradeoffs worth considering.

The practical difference: Netlify's continuous deployment pipeline is genuinely framework-agnostic, which matters when a project mixes Astro for marketing pages and SvelteKit for the app shell. Vercel is the stronger choice when the entire stack is Next.js and you want ISR semantics tightly integrated with the build pipeline. On the free tier, Vercel's 6,000 build minutes versus Netlify's 300 is a meaningful gap for teams running frequent CI jobs (Autonoma AI - Netlify vs Vercel: A Developer's Guide).

From our own project work, Netlify's atomic deploy rollback is the feature engineers trust most during high-traffic releases: reverting a bad deploy is a single button press with zero downtime, and the immutable deploy URL means the previous state is still live and testable while the fix is being staged.

Netlify pros, cons, and honest tradeoffs

Netlify's strongest advantages are developer experience, atomic deploys with one-click rollback, and enterprise-grade security: Netlify holds SOC 2 Type II certification, making it a credible choice for teams with compliance requirements (Netlify Security page).

Deploy previews accelerate code review workflows in ways that generic CI/CD pipelines rarely match out of the box.

The tradeoffs are real, though. Build-minute caps bite quickly on JAMstack projects with many dependencies. The free tier includes only 300 build minutes per month, and overages add up fast (Netlify Support Forums). Serverless functions on Netlify work well for simple API proxies and form handling, but Next.js SSR support still lags Vercel's native implementation: features like Incremental Static Regeneration require workarounds that Vercel handles natively. For data-heavy server-rendered builds, that gap matters, especially when privacy concerns arise around data transmission.

Honest verdict: Netlify fits content-driven, JAMstack-architecture projects where deploy confidence and security compliance carry more weight than bleeding-edge framework parity. If your project is a Next.js app with heavy SSR, Vercel is the more direct path.

Netlify AI-native development: Agents and MCP server

Netlify's AI-native development layer targets a genuinely new workflow: an AI agent generates code, Netlify builds and deploys it, and the result is live on the global CDN edge network, all without a developer touching a terminal. The platform's Model Context Protocol (MCP) Server gives AI agents direct read/write access to Netlify project data: they can trigger builds, inspect deploy logs, manage environment variables, and promote a deploy preview to production via API calls the agent orchestrates autonomously.

In practice, this is the same continuous deployment pipeline that JAMstack teams already trust, extended so that an AI agent, not a human, sits at the commit end, with security and compliance details available in your trust center. Edge functions serve the resulting site with the same invocation model as any standard Netlify deploy. For enterprise teams with compliance questions about who or what can push to production, the MCP Server's OAuth-scoped credentials mean agent actions are auditable and secure by default.

Frequently asked questions about Netlify

Is Netlify the right platform for your project?

Netlify fits best when your project runs on a JAMstack architecture, a static or hybrid frontend with APIs handling dynamic data. For a marketing site, docs portal, or SaaS frontend with a continuous deployment pipeline fed from Git, Netlify's build-to-CDN-edge workflow removes most of the infrastructure overhead your team would otherwise own.

E-commerce with heavy server-side personalization, or enterprise apps with strict HIPAA-compliant security requirements and custom network controls, may need a platform with deeper backend flexibility.

If you're weighing Netlify against other options for a new web build or a legacy migration, our team can walk through the tradeoffs. Talk to our team, we've shipped JAMstack projects across Netlify, Vercel, and custom pipelines, and we'll tell you which stack fits your data model and compliance posture, not just your deploy workflow.