Netlify helped define what modern web deployment looks like. Before Netlify, deploying a static site meant uploading files to an S3 bucket, configuring CloudFront, and hoping you got the cache invalidation right. Netlify turned that into a git push. Push to main, site builds, site deploys to a global CDN. Done.
That simplicity is still Netlify's core strength. But the platform has grown well beyond static site hosting, and understanding what it does (and does not do) well is important if you are evaluating deployment options.
What Netlify Actually Is
At its core, Netlify is a build and deployment platform for web projects. You connect a Git repository, Netlify watches for changes, runs your build command, and deploys the output to their CDN. Every pull request gets a preview deployment. Every merge to production gets a production deployment.
On top of that foundation, Netlify has added:
- Serverless functions. AWS Lambda functions that deploy alongside your site. Write a JavaScript or TypeScript function, put it in a functions directory, and Netlify handles the rest... packaging, deployment, and routing.
- Edge functions. Code that runs at the CDN edge, powered by Deno. Useful for personalization, A/B testing, authentication, and request modification without a round-trip to a central server.
- Forms. Built-in form handling that captures submissions without a backend. Add a netlify attribute to an HTML form and submissions appear in your Netlify dashboard or get forwarded to an email or webhook.
- Identity. Built-in authentication service for adding user login to your site. Based on GoTrue, it handles registration, login, and token management.
- Large Media. Git LFS integration for handling large files (images, videos) without bloating your repository.
Where Netlify Shines
The Jamstack workflow. Netlify was built for the Jamstack architecture (JavaScript, APIs, Markup), and that workflow is still where it excels. If your site is a static site generator (Hugo, Gatsby, Eleventy, Astro) that pulls content from a headless CMS and deploys to a CDN, Netlify makes the whole pipeline frictionless.
Preview deployments. Every branch and every pull request gets its own URL with a fully built version of the site. This is invaluable for design reviews, content reviews, and QA. Share a preview link with a stakeholder, get feedback on the actual site, not a screenshot or a staging environment that might be out of date.
Atomic deployments. Deployments on Netlify are atomic... the entire site switches to the new version at once. There is no partially-deployed state where some pages are old and some are new. If the build fails, the previous version stays live. You can roll back to any previous deployment with one click.
Build plugins. Netlify's build plugin ecosystem lets you hook into the build process to run custom logic. Lighthouse audits on every build, cache optimization, sitemap generation, image optimization... these run as part of your build pipeline without custom CI/CD configuration.
Where Netlify Struggles
Being honest about limitations is more useful than a feature list:
Server-side rendering at scale. Netlify supports SSR through serverless functions and edge functions, but it was not built for it the way Vercel was built around Next.js. If your application relies heavily on server-side rendering... dynamic pages, API routes, middleware... Vercel's integration with Next.js is tighter and more performant.
Build times for large sites. Static site generation means building every page at build time. For sites with thousands of pages, builds can take minutes. Netlify has improved this with incremental builds and distributed persistent caching, but if your build time is a problem, you may need to rethink the architecture (incremental static regeneration, deferred static generation) rather than optimize the build.
Function cold starts. Netlify's serverless functions run on AWS Lambda. Cold starts add latency to the first request after a function has been idle. For latency-sensitive endpoints, this can be noticeable. Edge functions reduce this by running closer to the user, but they have their own constraints (Deno runtime, limited dependencies).
Vendor lock-in on add-ons. Netlify's built-in services (Forms, Identity, Large Media) are convenient but proprietary. If you build on them and later want to move to a different platform, you need to replace those services. Using third-party alternatives (Formspree for forms, Auth0 for auth, Cloudinary for media) keeps your options open.
Netlify vs. Vercel: The Real Comparison
This is the comparison everyone wants, so let us address it directly.
| Dimension | Netlify | Vercel |
|---|---|---|
| Best for | Static-first sites, Jamstack | Next.js, SSR-heavy applications |
| Framework support | Framework-agnostic | Best with Next.js (they maintain it) |
| Built-in services | Forms, Identity, Large Media | Image optimization, Analytics |
| Edge runtime | Deno-based edge functions | Edge Runtime (Node.js subset) |
| Pricing model | Per-site bandwidth, team seats | Per-user, usage-based overages |
| CLI experience | netlify dev for local development | vercel dev, tighter framework integration |
The short answer: if you are building a Next.js application, Vercel is the natural choice because they build and maintain the framework. If you are building a static site with any generator, or if you want to stay framework-agnostic, Netlify is an excellent choice. Both platforms are mature, reliable, and well-supported.
Getting Started with Netlify
The onboarding experience is one of Netlify's strengths. The basic workflow:
- Sign up and connect your Git provider (GitHub, GitLab, Bitbucket)
- Select a repository
- Configure build settings (build command, publish directory)
- Deploy
For most static site generators, Netlify auto-detects the framework and pre-fills the build settings. An Astro project gets npm run build as the build command and dist as the publish directory automatically.
After the initial setup, add a netlify.toml file to your repository root for version-controlled configuration. This file defines build settings, redirect rules, headers, and plugin configuration... keeping your deployment config in your repo instead of in the Netlify dashboard.
How We Use Netlify
At Last Rev, we use Netlify for static-first projects where the Jamstack workflow is the right fit. The preview deployment workflow is particularly valuable for our agency work... clients can review changes on a real URL before anything goes to production. No staging environment to maintain, no "it works on my machine" conversations.
For projects that need heavy server-side rendering, we typically go with Vercel or a custom deployment setup. The tool should match the architecture, not the other way around.
If you are evaluating deployment platforms and want an honest conversation about which one fits your project, let's talk through the options.