Cloud & Deployment3 min read
Choosing a hosting provider: a checklist that survives year two
Every host looks fine on day one. The differences show up when traffic triples, a region goes down, or you need to leave.
Vercel gives you zero-configuration Next.js hosting with previews, edge caching, image optimisation and ISR that work out of the box — ideal until platform cost or control requirements dominate. AWS costs less at high traffic and gives complete control, but you own the CDN, cache invalidation, image pipeline and deployment tooling that Vercel provides for free.
| Capability | Vercel | AWS (self-managed) |
|---|---|---|
| Setup time | Minutes | Days to weeks |
| Preview deployments | Automatic per PR | Build it yourself |
| ISR / on-demand revalidation | Native | Needs shared cache + invalidation |
| Image optimisation | Built in | Lambda/CloudFront or a third party |
| Edge network | Included | CloudFront, configured by you |
| Cost at low traffic | Free to modest | Low, plus your time |
| Cost at high traffic | Grows with bandwidth | Usually lower per GB |
| Control and compliance | Platform-defined | Complete |
For most of the client sites we build, the platform bill is a rounding error next to the engineering time saved. That calculation changes with scale, not with principle.
None of this is exotic; Next.js documents self-hosting well and the community tooling is mature. Just cost it honestly as a project, not a configuration change.
Yes, and it is where a lot of teams land. Keep the front end on Vercel for the developer experience, and run your APIs, workers, and databases on AWS where per-unit costs are lower and control matters. Watch cross-provider latency and egress, and keep the boundary at a small number of chatty-free calls.
Platforms like Railway, Render, Fly.io and Cloudflare sit between the two, offering container hosting with far less setup than raw AWS. For many mid-size projects they are the better answer than either extreme.
It depends far more on bandwidth and function execution than on page views. Model your own numbers against current pricing — teams serving large media hit it much earlier than content sites.
Yes. Self-hosting is officially supported and documented. Some capabilities need infrastructure you configure — shared ISR cache, image optimisation, edge routing — but nothing is locked away.
Strong on bandwidth pricing and global edge, with improving Next.js support. Evaluate your specific feature usage carefully, since runtime differences affect what works.
Containerise, keep configuration in environment variables, avoid platform-specific APIs in application code, and keep infrastructure defined as code. That keeps the migration a project rather than a rewrite.
Harshal Patel
Founder & Lead Engineer, ROVQIX
Harshal leads engineering at ROVQIX, where he has shipped production Next.js, Node.js and PostgreSQL systems for startups, SaaS teams and ecommerce brands. He writes about the trade-offs behind architecture decisions rather than the framework of the week.
ROVQIXdesigns and builds production web platforms — Next.js front ends, Node.js APIs and the infrastructure behind them. Tell us what you're building and we'll scope it with you.
Every host looks fine on day one. The differences show up when traffic triples, a region goes down, or you need to leave.
Most cloud bills have 30% of obvious waste in them. Finding it takes an afternoon; the hard part is having the conversation about what to turn off.
Launch day problems are almost never novel. This is the list that catches them — the same one we run on every client deployment.
No spam. Just the occasional case study and craft breakdown.