DEV Community

Cover image for Self-hosted Next.js - When Vercel is Not an Option
Focus Reactive for FocusReactive

Posted on with Robert Haritonov • Originally published at focusreactive.com

Self-hosted Next.js - When Vercel is Not an Option

This article is the first one of the in-depth series about self-hosted Next.js and the challenges around it.

We've been big fans of server-rendered React since 2016, its performance and ability to morph the best of server rendering with highly dynamic client-side apps has made it a go-to choice for most of the industry. When React SSR and static-generated websites went mainstream, it quickly became apparent that re-inventing its flavor of a "React Framework" for each project was not viable and not scalable. Enter Next.js, the new go-to React Framework, universally chosen for most new React web projects.

Not surprising that Next.js popularity and adoption grew so big, so fast, that a "native" hosting emerged from the same authors - Vercel, which since their post-docker days, has been increasing it's preffered hosting platform dominance, and is currently almost the only way to ship Next.js apps.

While we love Vercel as much as we love Next.js, it's not always possible to use it as a primary hosting solution, whether because of cost management, preference towards existing cloud solutions, or when the serverless environment is simply not suitable for your Next.js application.

In this series of articles, we will share some of our experience and investigate in-depth when and how to self-host the Next.js applications and website, and when it's worth considering Vercel alternatives.

Why pick alternative Next.js hosting

Firstly, let's not forget, that Next.js is an open-source project and its authors and developers are going the extra mile to ensure that Next.js is not becoming a proprietary framework. Sure, Next.js is opinionated, and some strong opinions are well aligned with how Vercel functions, but it is meant to be hosted whenever you like, whether it's Vercel's competitor, your own cloud, or even your laptop.

To our opinion, amongst many others, the biggest limiting factors are the following:

  • Your company (or your client) are bound to certain cloud, like AWS
  • Serverless runtime is not suitable for your needs

While the first one is more straightforward, and not only driven by the company policy but also the need to have the Next.js app close to your data and other internal infrastructure; the second could be more nuanced.

Serverless is great for infinite scaling (think Black Friday), but it can be much more expensive than more traditional servers, which you can cost manage with more accuracy and scale up and down based on your needs. There are several other challenges that take time to be tamed, like connections to database from Serverless env, cold starts and etc.

There is also a strong movement towards the Edge runtimes (Next.js middleware, Cloudflare Workers), which possibly will replace Serverless one day, but it will take a long cycle of ecosystem development.

But "classic" servers will always remain as a proven, independent (no vendor lock-in), go-to solution for many. And this is what we want to talk about.

Where to host the Next.js article series

It will take a whole book (or a few) to cover multiple aspects of Next.js specifics in the wild, how self-host compares to Vercel, and how various challenges can be solved efficiently and better for your use case compared to Vercel.

So let's break this series down to a series of more focused articles, brought to you by technology enthusiasts from FocusReactive, an expert Next.js consultancy and web development agency.

Note that some articles are currently in the works, and once published, will be linked from this page with ongoing updates.

Top comments (0)