Where Next.js runs well
| Platform | SSR | ISR | Edge | Effort |
|---|---|---|---|---|
| Vercel | ✅ | ✅ (global CDN) | ✅ | Zero-config |
| Netlify | ✅ | ✅ (DPR) | ✅ | Easy |
| AWS Amplify | ✅ | ✅ | Limited | Medium |
| Cloudflare Pages | ✅ | Limited | ✅ | Medium |
| Railway / Fly.io | ✅ | ✅ | ❌ | Easy |
| Docker on any cloud | ✅ | ✅ | ❌ | Manual |
Trade-offs of leaving Vercel
- ISR cache lives in one region rather than globally.
- Image optimization needs
sharpor a custom loader. - No automatic preview URLs — you set up your own staging environment.
- SSL, scaling, observability all become your problem.
Choose a host from the features the application actually uses: runtime and regional needs, ISR and invalidation semantics, image optimization, streaming, previews, logs, cost, and rollback. Test the chosen adapter or container against a real production build before migration. Portability is more than starting one container. Replace instances under traffic, clear caches, and exercise image processing and scheduled work. Sessions, uploads, and centralized logs must survive, and measured recovery time makes platform convenience comparable with self-hosting labor.
Leaving Vercel is neither automatically cheaper nor automatically more portable. Provider integrations may need replacement, while a disciplined container can still depend on framework behavior. Count operational labor and degraded features as migration cost. Deploy the same representative routes to the candidate platform and exercise SSR, streaming, mutations, images, cache invalidation, environment promotion, logs, and rollback. Compare cold starts, region latency, and monthly cost at expected traffic rather than relying on a feature table.