Astro can run as a static site or render pages on demand. That decision should come before the hosting decision.
If every route can be generated at build time, you can deploy the output to a static host and avoid a server runtime entirely. If the application needs request-time rendering, server actions or other dynamic behaviour, choose a provider with an Astro adapter and understand how that runtime is billed.
This guide compares Vercel, Cloudflare and Netlify using their published documentation. It is a feature and workflow comparison, not a benchmark: no identical workload has been deployed to all three providers for this article.
Start with Astro's rendering mode
Astro builds static output by default. A static project does not need a hosting adapter: build it and publish the generated dist/ directory.
Use on-demand rendering only when a route genuinely needs request-time work. That requires setting the appropriate output mode and installing the adapter for the chosen host.
Before comparing providers, list what the project actually needs:
- Static pages and assets only, or server-rendered routes?
- Forms, API endpoints or other server functions?
- Preview deployments for pull requests?
- Scheduled jobs, storage, databases or queues?
- What are the expected traffic and build patterns?
- Which logs, rollback and access controls are required?
A static portfolio and a multi-tenant SaaS application have different hosting requirements. Do not pay for or operate a server runtime just because the framework supports one.
At a glance
| Provider | Strong fit | Main trade-off |
|---|---|---|
| Vercel | Git-based workflow, previews and integrated framework deployment | Usage-based costs and plan terms need attention as a project grows |
| Cloudflare | Static asset delivery and applications already using Cloudflare's network | Dynamic features use the Workers platform and its runtime model |
| Netlify | Straightforward Git deploys, previews and integrated site tooling | Current credit-based usage needs to be modelled, not compared using old bandwidth quotas |
There is no universal winner. For a static Astro site, all three can serve generated files. The deciding factors are usually the existing infrastructure, preview workflow, dynamic requirements and cost model.
Vercel
Vercel provides Git-connected deployments, preview environments, custom domains and a managed delivery network. Astro's official deployment guide supports both static output and on-demand rendering through the Vercel adapter.
For a static site, Vercel can deploy Astro's default output without an adapter. For request-time rendering, install the adapter using:
npx astro add vercel
The Vercel Hobby plan is listed at no monthly charge for personal, non-commercial projects. The Pro plan is listed at $20 per month and includes usage credit; additional usage is billed according to the current pricing schedule. Prices are in USD and exclude applicable taxes.
Choose Vercel when its Git workflow, preview deployments and framework integration remove operational work for your team. Check the Hobby plan's permitted use, included usage, team requirements and function costs before treating it as a long-term production budget.
Official references: Astro on Vercel · Vercel pricing
Cloudflare Pages and Workers
Cloudflare Pages is a strong option for static sites that fit its build and deployment model. Its documentation currently lists 500 builds per month and one concurrent build on the Free plan, with a 20-minute build timeout. Static asset requests are free on both Free and paid Pages plans.
Dynamic Pages Functions are billed as Workers. Cloudflare's Workers Paid plan has a $5 monthly minimum and includes a defined amount of usage, with additional charges based on the published pricing model. Cloudflare states that Workers Paid does not add separate data-transfer or throughput charges.
For Astro, distinguish between a static Pages deployment and an application that needs the Cloudflare adapter and Workers runtime. They are not the same cost or operational model.
Choose Cloudflare when static delivery is the main requirement, or the application already uses Workers, KV, Durable Objects or other Cloudflare services. Confirm compatibility and runtime limits for the adapter and APIs you need.
Official references: Astro deployment guide · Pages limits · Workers pricing
Netlify
Netlify supports Git-connected builds, deploy previews, custom domains and functions. Astro can be deployed as a static site, or use the Netlify adapter when request-time rendering is required.
The current Free plan is listed at $0 with a monthly limit of 300 usage credits. Netlify's credit model counts different resources separately: production deploys, compute, bandwidth and web requests. A production deploy currently consumes 15 credits; bandwidth consumes 20 credits per GB. Personal and Pro plans provide higher monthly credit allowances.
This is materially different from older comparisons based on a fixed free bandwidth allowance. Calculate expected usage using the current credit rules rather than copying a historical plan table.
Choose Netlify when its deploy workflow and integrated site features suit the project, and the expected deploy and traffic pattern fits the credit budget.
Official references: Netlify pricing · Netlify pricing FAQ
How to make the decision
Use this order:
- Prefer static output where possible. It is simpler to host and avoids request-time compute for pages that do not need it.
- Confirm adapter support. Check the current Astro adapter documentation and the platform APIs your application depends on.
- Model the real workload. Estimate builds, bandwidth, requests, function execution and storage from actual usage.
- Test the deployment workflow. Verify previews, environment variables, redirects, headers, logs and rollback on a representative project.
- Check plan terms. Personal-use restrictions, team seats and usage limits matter as much as the headline monthly price.
- Keep the exit path clear. Avoid unnecessary platform-specific dependencies when a static build or standard web API will do.
Do not choose a provider because a table says it is fastest or cheapest. Those claims depend on region, workload, caching, runtime and configuration. Measure the routes that matter to your users.
Recommendation
For a static Astro site, choose the provider that gives you the simplest reliable Git-to-production workflow at an acceptable cost. For a dynamic Astro application, compare the adapter and runtime model before looking at the headline plan price.
The best deployment is the least complicated option that meets the application's actual requirements.