Skip to content
Back to writing
Published January 01, 2026

Is Next.js always the right choice? Maybe not if you are strictly self-hosting.

The "Vercel Magic" is real: Vercel abstracts away massive complexity regarding Edge computing and CDN distribution. Replicating this manually on AWS is painful.

2 min readNext.jsReact.jsAWSWeb Development

We recently kicked off a project betting big on Next.js.

The goal was simple: leverage its powerful caching system and Server-Side Rendering (SSR) for top-tier performance.

However, we had a strict constraint: No Vercel (https://vercel.com/). We had to manage the infrastructure entirely within our own AWS environment.

This turned out to be our biggest bottleneck.

Here is what we learned:

πŸ”· The "Vercel Magic" is real: Vercel abstracts away massive complexity regarding Edge computing and CDN distribution. Replicating this manually on AWS is painful.

πŸ”· Caching Nightmares: Without the native infrastructure Next.js expects, the caching strategy became our arch-nemesis, causing more bugs than performance gains.

πŸ”· The Pivot: To make it work with CloudFront and our rigid infra, we had to strip away the SSR and server caching strategies.

In the end, we essentially turned Next.js into a standard client-side router/renderer functioning almost exactly like a pure React app.

The takeaway? Tools like OpenNext (https://opennext.js.org/) are great, but in a restricted, managed infrastructure, the friction is high. If you can't use the platform designed for the framework (Vercel), simpler might be better.

The takeaway? Tools like OpenNext (https://opennext.js.org/) are great, but in a restricted, managed infrastructure, the friction is high. If you can't use the platform designed for the framework (Vercel), simpler might be better.