Who is the host with the most? Since circa 2015, the high-control, high-investment public cloud model has been joined by a new approach.
Platforms like Vercel, Netlify, and the more flexible Cloudflare all offer a simpler, developer-focused hosting experience for Jamstack/static sites.
Many devs prefer these platforms, sitting as they often do, above public cloud servers they themselves no longer have to deal with.
But does that simplicity come with a price? Might you be better off hosting your backend with the big three (where you stay in control) and using Vercel or Netlify for frontend? These questions of trade-offs, combinations and modern hosting strategies are answered below.
Who is this guide for?
This guide is for the types of teams who will be wondering about deploying to one or a combination of these platforms and the public cloud.
You might be:
- A SaaS product team thinking about deploying your Next.js web app to Vercel and your backend on AWS
- A marketing or website platform team that is already on Netlify for sites and is asking whether to move the app surface there too, or keep it in Azure
- An agency or consultancy that has to recommend an approach to clients and wants to shore up/evolve its position
What’s in this guide?
Below, we’ll be helping you make up your mind by providing:
- A quick technical fact sheet for each platform and combination
- A decision overview for the same
- A final, scored quiz so you can be sure of your choice
Let’s begin.
Cloudflare only – technical factsheet
Core pieces: Cloudflare Pages (Git to build to deploy), Workers or Pages Functions to run backend code at the edge, Cloudflare DNS, HTTPS and CDN in front.
Pages (free) numbers: 1 concurrent build, 500 builds per month, up to 100 custom domains per project, unlimited static requests and bandwidth, very friendly for lots of small sites.
Workers numbers (2025): free around 100,000 requests per day; paid from $5 per month, with 10 million requests per month included, then per million and per CPU millisecond overages, so the meter is on functions, not on static.
Security baked in: automatic SSL, DDoS protection (unmetered), WAF features at the edge; you do not bolt these on later.
Data and services available: KV, R2 (object storage, no egress fees), D1 and Durable Objects for stateful style bits, or call out to an external database if you have sensitive data.
Config surface: build parts in repo, Workers bindings, routes, WAF and logs in the Cloudflare dashboard or CLI, that is the one setup quirk.
Network: large global edge, good default load times and performance even before you optimise.
Cloudflare only – decision view
What it optimises for
Putting the whole public web surface (DNS to TLS to CDN to hosting to light logic) on one edge platform, with strong protection and no egress worries for static.
When it feels great
- You want to git push to Pages and have it auto-deploy globally
- You need to run backend code for forms, authentication, request transforms, but only in short, edge-style bursts
- You like that static delivery is effectively unlimited bandwidth, so high traffic sites do not surprise you
Where it fights you
- You must keep sensitive data in a VPC or private network
- You need long-running, stateful or back-office servers
- You want every single setting in code; some of it will live in Cloudflare
Cost shape
- Cheap or free for static and Jamstack, and a bit of Workers
- Grows mainly with Workers CPU and time, and with extra Cloudflare services (KV, R2, D1)
- Static CDN, TLS and DDoS stay bundled, so the expensive part is compute, not bandwidth
Key technicals to remember
- Custom domains and SSL are automatic
- You can attach storage (KV or R2) without leaving the platform
- You get security features (DDoS and WAF) on the hosting, not via another provider
Key contrasts
- vs. Vercel or Netlify: Cloudflare is the stronger perimeter (DDoS, DNS, CDN first); Vercel and Netlify are nicer for framework or repo-centric developer experience
- vs. Cloudflare plus public cloud: this is the smallest, cheapest setup, but it is the first to hit a wall when you need private or VPC workloads
- vs. other platforms that meter bandwidth: Cloudflare Pages giving you unlimited bandwidth for static means popular websites are safer here
Cloudflare + public cloud – technical factsheet
Core pieces: Cloudflare still does DNS, HTTPS, CDN, DDoS protection, WAF, load balancing and can run backend code at the edge (Workers or Pages Functions). The actual app or data lives on AWS, GCP or Azure inside VPCs or managed services.
Traffic flow: user to Cloudflare edge (TLS, WAF, caching, image optimisation, access rules) to origin in the cloud (API Gateway, VM, container, storage, whatever). Cloudflare can sit in front of almost any HTTPS origin, not just a single framework app.
Pages and Workers numbers: you can still use Cloudflare Pages for the static or front part (1 concurrent build, 500 builds per month, unlimited static requests and bandwidth) and Workers for edge logic (free about 100,000 requests per day, paid from $5 per month with 10 million requests per month). But most heavy lifting now happens in the cloud.
Security baked in: Cloudflare gives you unmetered DDoS protection, TLS or SSL, IP or country rules, bot and WAF controls at the edge; the cloud keeps private networks, security groups, IAM, and stores sensitive data.
Origins or providers: can front multiple origins (for example, AWS for APIs, GCP for ML, on-premises for legacy) from the same Cloudflare account using hostnames, routes and load balancing.
Config surface: edge parts (routes, Workers bindings, WAF, DNS) stay in Cloudflare; origin or app parts (VPC, databases, serverless, containers) stay in the cloud. Two clear admin planes.
Network: Cloudflare’s large edge shortens latency for users and shields the cloud origin from direct internet traffic.
Cloudflare + public cloud – decision view
What it optimises for
Putting a strong, global, security-first edge in front of one or more cloud backends, so users hit Cloudflare and only Cloudflare talks to your VPC or private services.
When it feels great
- You have apps or APIs in AWS, GCP or Azure that must stay private or stateful, but you still want CDN, TLS, DDoS and edge logic out front
- You want to serve static websites or assets from Cloudflare Pages, but call into cloud APIs for data
- You need to front more than one origin or service (microservices, legacy, even other platforms) from the same edge
Where it fights you
- You want to define everything in one repo, here it is deliberately split (Cloudflare for edge, cloud for app or data)
- You have an extremely chatty, low-latency app to database calls from the browser; those still pay the round trip to the cloud region
- Teams are not aligned on who owns which layer (edge vs. cloud), you need that written down
Cost shape
- Cloudflare side stays relatively cheap for static, DNS, TLS, DDoS and moderate Workers use
- The big or variable part is in the cloud (compute, database, egress), Cloudflare is mostly reducing exposure and offloading traffic, not replacing that bill.
- You can sometimes lower cloud egress because more is cached or delivered at the edge
Key technicals to remember
- You can run backend code at the edge (Workers) before you hit the cloud, good for auth, header transforms, AB tests
- Custom domains and SSL stay at Cloudflare even though the app lives in the cloud
- Load balancing and health checks can spread traffic across multiple cloud regions or origins
Key contrasts
- vs. Vercel plus cloud or Netlify plus cloud: Cloudflare can sit in front of almost anything (APIs, legacy, multiple services), not just a frontend that calls a single backend
- vs. Cloudflare only: this version is how you bring in private or VPC data and heavy workloads without losing Cloudflare’s edge or security
- vs. running only in the cloud: you get better global performance and DDoS or WAF or TLS without having to build it all with cloud-native services
Vercel only – technical factsheet
Core pieces: Vercel hosting for modern React or Next.js apps, global CDN, serverless functions (Node first, but other functions are available), Edge Functions (closer to users), automatic image optimisation, custom domains or SSL, and preview deployments.
Plans (free or entry) numbers: free tier gives roughly 100 GB per month of bandwidth, around 100,000 serverless function invocations per month, and CI or builds from git, good for personal sites, prototypes and small projects.
Team or Pro numbers: typical Pro plan (per user) lifts bandwidth to about 1 TB per month and includes ~1 TB bandwidth, ~1,000,000 serverless function invocations, and ~10,000,000 edge requests before overages; the meter here is on dynamic work and transfer, not on having a project.
Security baked in: automatic HTTPS or SSL for custom domains, basic WAF or DDoS features for the app surface, no separate certificate setup.
Data or services available: Vercel expects you to call out to external databases, storage or other services for stateful data or sensitive data; on platform is for request-time app logic, not for running your main database.
Config surface: build or framework settings mostly live in the repo (for example, next.config.js, vercel.json); environment variables and project-level toggles live in the Vercel dashboard, cleaner and more repo-centric than dashboard-heavy setups.
Network: global edge tuned for Next.js, good default load times, image optimisation and ISR or SSR support without extra CDN rules.
Vercel only – decision view
What it optimises for
Shipping a Next.js-style app fast, with the platform doing the framework-specific work (routing, ISR, image optimisation) and giving preview deployments on every git push.
When it feels great
- Your frontend is already in that ecosystem
- Your developers want push to preview every time
- You do not want to design CDN, build, and SSL yourself
Where it fights you
- You need long-running, stateful or VPC-only services
- You want one edge in front of lots of unrelated origins
Cost shape
- Stays low while pages are mostly static or ISR and function calls are modest
- Climbs when you push real traffic or make lots of serverless or edge calls
Key contrasts
- vs. Cloudflare and Netlify: Vercel is the most framework-aware (especially for Next.js); the other two are broader as generic edge or CDN hosts
- vs. Vercel plus public cloud: this is the fastest to ship, but it is the first to hit the need a real database or private network ceiling
Vercel with public cloud provider – technical factsheet
Core pieces: Vercel controls the web or app runtime itself (Next.js build, SSR or ISR, image optimisation, previews, custom domains or SSL). The public cloud (AWS, GCP, Azure) supplies the things Vercel does not host, databases, queues, VPC only or internal services. Unlike Cloudflare plus provider, Vercel is not acting as a generic edge in front of any origin; it is running your app and then reaching out to the cloud.
Vercel (free) numbers: about 100 GB bandwidth per month, about 100,000 serverless function invocations per month, git-based deployments and preview URLs per push, enough for a real frontend that talks to shared cloud APIs.
Vercel (Pro or team) numbers: about 1 TB bandwidth per month and about 1,000,000 serverless function invocations, and about 10,000,000 edge requests before overages, sized for the app layer, not for pushing all backend or API traffic through Vercel.
Security baked in: Vercel handles HTTPS or SSL, custom domains and app surface WAF or DDoS; the cloud side keeps IAM, VPC, security groups and stores sensitive data.
Data or services available: app-level logic stays on Vercel (route handlers, small API routes); application data, AI services, background jobs and regulated data are reached in the cloud via secured endpoints.
Config surface: Vercel project for build, environment, domains and previews; cloud project for APIs, databases and networking, two separate configuration planes on purpose.
Network: Vercel serves the page shell or static from its edge POPs; dynamic calls traverse to the cloud region you picked, so user-to-cloud distance shows up as latency.
Vercel with public cloud provider – decision view
What it optimises for
Keep Vercel’s opinionated, framework-aware shipping (preview on every PR, ISR, image optimisation) while parking real data and private services in the cloud.
When it feels great
- Teams want to keep push to preview for the UI, but must keep production data in AWS, GCP or Azure
- Product or UX can move fast on Vercel while platform or security gatekeep the cloud side
- Many preview deployments all need to talk to the same cloud API or database
Where it fights you
- CORS or auth between Vercel and the cloud is not documented, previews break.
- Cloud region is far from users, page is fast, data is slower
- You try to make Vercel the universal front door, that is the Cloudflare plus provider pattern, not this
Cost shape
- Vercel cost grows with web or app traffic and function runs
- Cloud cost grows with real workloads (database, compute, egress)
- Very chatty frontends make the cloud bill grow faster than the Vercel one
Key contrasts
- vs. Cloudflare plus provider: Vercel is app or runtime led, Cloudflare is edge or security led and can front arbitrary origins
- vs. Vercel only: this adds a place for private or stateful services without giving up Vercel’s developer experience
- vs. Netlify plus provider: Vercel brings more Next.js js-specific automation, Netlify’s is a more generic Git to CDN split
Netlify only – technical factsheet
Core pieces: Netlify builds from Git, deploys to its global CDN, and runs Netlify Functions/Edge Functions alongside the site. Custom domains and SSL are included.
Netlify (free/entry) numbers: about 100 GB/month of bandwidth, ~300 build minutes/month, 1–3 concurrent builds, ~125,000 function invocations and up to 1M edge function invocations — enough for marketing/docs and smaller apps.
Security baked in: automatic HTTPS/SSL for custom domains, basic traffic controls/redirects, form handling and identity features; not the same unmetered DDoS/WAF depth as Cloudflare.
Data/services available: built-ins for forms, file uploads and calling external APIs; for databases, long-running jobs or sensitive data you integrate an external service.
Config surface: much of the setup can live in the repo via Netlify.toml (build, redirects, headers, edge functions), with environment variables and site-level settings in the Netlify dashboard.
Network: content is served from Netlify’s CDN POPs, giving good default load times for static/Jamstack and public websites.
Netlify only – decision view
What it optimises for
Git to build to global deploy for static, Jamstack, marketing or docs sites, with just enough functions and edge logic to make them interactive.
When it feels great
- You want most config in the repo (Netlify.toml) so developers can review it
- You are shipping marketing, docs or product sites that hit external APIs or light functions
- You want to give frontend developers a straightforward way to add small bits of backend code without touching AWS
Where it fights you
- You need a stronger perimeter (full DDoS or WAF) like Cloudflare
- You want to run long-lived or heavy backend services
- You need private or VPC networking
Cost shape
- Low for typical web or marketing traffic
- Rises with function usage, build minutes and high bandwidth
- Extra external services (database, queues) add separate bills, because Netlify is not trying to be a full cloud
Key contrasts
- vs. Vercel only: Netlify is more generic Git to CDN with repo config; Vercel is deeper for Next.js and automatic image or ISR tuning
- vs. Cloudflare only: Netlify is nicer for keeping config in the repo; Cloudflare is stronger on edge, security and DDoS
- vs. Netlify plus provider: this is the simplest variant, once you need real databases or VPC, you add the cloud
Netlify with public cloud provider – technical factsheet
Core pieces: Netlify still builds and serves the frontend from its CDN (with functions or edge functions). The public cloud (AWS, GCP, Azure) runs the app’s heavier or backend parts, APIs, databases, VPC-only services.
Netlify (free or team style) numbers: enough build minutes and bandwidth to keep the public site on Netlify; function or runtime quotas are fine for site-adjacent logic, not for all backend traffic.
Security baked in: Netlify handles HTTPS or SSL and domain setup for the site; the cloud side enforces IAM, VPC, security groups and stores sensitive data.
Data or services available: small tasks (forms, light functions) can stay on Netlify; main app data, long-running jobs, AI and regulated data live in the cloud and are called from the site.
Config surface: site routing, redirects, headers, edge in Netlify.toml and site dashboard; cloud APIs, networking and databases in the cloud console or infra code, two separate configuration planes.
Network: site stays fast on Netlify’s CDN; dynamic calls go to the cloud region, so user-to-cloud distance affects latency.
Netlify with public cloud provider – decision view
What it optimises for
Letting the web team keep the easy Netlify Git to deploy flow and repo-based config, while the backend or platform team runs the real app or data in the cloud.
When it feels great
- You already have a good public site on Netlify and just need to add AWS, GCP or Azure APIs behind it
- Different teams own site vs. backend and do not want to share toolchains
- You want to keep Netlify’s simple domain or SSL story, even though the data is in a VPC
Where it fights you
- Frontend and backend deploy at different times and you do not document the API contract (CORS or auth), easy to break things
- Your cloud API is in one region and your users are far away, so dynamic bits feel slower
- You try to push a lot of backend logic into Netlify Functions instead of the cloud
Cost shape
- Netlify bill equals site traffic, builds and modest function usage
- Cloud bill equals actual backend workloads
- Very chatty frontends will show up on the cloud bill more than on Netlify’s
Key contrasts
- vs. Vercel plus provider: this is more generic Git to CDN; Vercel’s version adds deeper Next.js or runtime features
- vs. Cloudflare plus provider: Cloudflare can sit in front of many unrelated origins as a security or CDN edge; this Netlify pattern is one site here, APIs over there
- vs. Netlify only: same nice repo-driven setup, but now you can meet private or data requirements without moving the site off Netlify
Still can’t make up your mind…
Cloudflare vs. Vercel vs. Netlify Pop Quiz (pens, paper or paste to LLM at the ready)
Q1. What is the main thing you are deploying?
- Mostly marketing, docs, static sites, maybe a few forms (Netlify only +1, Cloudflare only +1)
- A Next.js or React product UI that developers touch all the time (Vercel only +1, Vercel with public cloud provider +1)
- A mix of public sites plus APIs or services in a cloud VPC (Netlify with public cloud provider +1, Vercel with public cloud provider +1)
- One edge, CDN, security front door in front of several backends (Cloudflare with public cloud +2)
Explainer: Vercel leans more app or framework; Netlify and Cloudflare are more natural for just sites, so 1A does not give Vercel points.
Q2. Where do you want most config to live?
- In the repo, reviewable in PRs (Netlify only +1, Netlify with public cloud provider +1)
- In the repo and with clean project or environment UX (Vercel only +1, Vercel with public cloud provider +1)
- OK with some of it in the platform dashboard (Cloudflare only +1)
- OK with a split (edge vs. cloud) (Cloudflare with public cloud +1)
Q3. How strong does the perimeter need to be?
- HTTPS plus custom domain is enough (Netlify only +1)
- App-level WAF or DDoS is enough (Vercel only +1, Netlify with public cloud provider +1)
- I want Cloudflare grade shielding (Cloudflare only +1, Cloudflare with public cloud +1)
- I must front multiple origins with rules (Cloudflare with public cloud +1)
Q4. Where is the real backend or data?
- Nowhere special or third-party APIs (Netlify only +1)
- App on platform, data in cloud (Vercel only +1, Netlify with public cloud provider +1)
- Must stay private or VPC (Cloudflare with public cloud +2)
- Several clouds or on-premises behind one edge (Cloudflare with public cloud +1, Vercel with public cloud provider +1)
Explainer: the moment you say private or VPC or multiple origins, the pure platform is not enough, that is why the plus public cloud variants get the heavier scores.
Q5. Tolerance for serverless meters running?
- Low usage, mostly static (Netlify only +1, Cloudflare only +1)
- Moderate app traffic, I know dynamic calls will cost (Vercel only +1)
- Static can be huge, I would rather pay for compute than bandwidth (Cloudflare only +1)
- Most cost will be in the cloud anyway (Cloudflare with public cloud +1, Netlify with public cloud provider +1, Vercel with public cloud provider +1)
Q6. What developer experience matters most?
- Git to build to CDN (Netlify only +1)
- Push to preview, Next.js just works (Vercel only +1, Vercel with public cloud provider +1)
- DNS, TLS, WAF plus edge functions (Cloudflare only +1)
- Frontend happy, platform or security own the cloud (Cloudflare with public cloud +1, Netlify with public cloud provider +1)
Explainer: Netlify is the site team feel, Vercel is the product or Next.js team feel, Cloudflare is the edge or network feel, pick the vibe that matches your organisation.
Q7. Do you need to front more than one origin or service?
- No, it is one site (Netlify only +1, Vercel only +1)
- Mostly one app, plus some APIs (Vercel only +1, Netlify with public cloud provider +1)
- Yes, and I want the edge to do that (Cloudflare only +1)
- Yes, and some of them are private or cloud only (Cloudflare with public cloud +1)
Q8. Biggest thing that has bitten you before?
- Platform was overkill for marketing sites (Netlify only +1)
- Platform did not understand my framework features (Vercel only +1)
- I could not keep sensitive data private (Cloudflare with public cloud +1)
- Frontend and backend deployed separately and broke auth or CORS (Vercel with public cloud provider +1, Netlify with public cloud provider +1)
How we can help
If your score still leaves you guessing, do not worry. At Just After Midnight, we have helped countless partners host their applications in the right environment.
From our work with agencies hosting and supporting mission-critical client sites, to partnering with major SaaS platforms to deliver on complex infrastructure needs, we have run the gamut in building, configuring and optimising cloud environments for every use case.
If you’d like to speak with one of our team, just get in touch.
