Platform Compare
When you are deciding on how to host your Next.js application, it is importent that you understand how the hosting of your application on Vercel works. In the end, this is the solution every other hosting option is compared to.
Where/how the code runs
When hosting your Next.js app on Vercel your application is running as a distributed application.
Some part of your Next.js application is e.g. running as a serverless function and some part of your code is running as an edge function/worker and not in a single Node.js process on a single server (e.g. when hosting via Docker).
For a little more background and context on that check out the self hosted entry page.
OpenNext (with the provider SST) is the only solution that attempts to replicate this distributed infrastructure, when hosting your Next.js application with it. This makes the application runtime environment somewhat comparable to Vercel.
For a broad overview check out the following table to better understand how the code infrastructure works for the different platforms:
Infrastructure Feature | Vercel | OpenNext | Docker |
---|---|---|---|
Function splitting | |||
Multiple deployment targets1 | |||
Serverless | ()2 | ||
External Middleware | ()3 | ||
External Image Optimization | |||
Edge runtime support | ()4 | ()5 | |
ISR | |||
On-Demand Revalidation |
Heavily inspired by: https://opennext.js.org/aws/comparison
(1) Deploy the same app to different targets like AWS ECS, Lambda, etc.
(2) Docker container can be deployed in a serverless environment. Not all Next.js features are going to work as expected though
(3) Opt-in feature
(4) No out of the box functionality. Needs additional configuration
(5) Uses "fake" edge runtime running in the container
Do not jump to the conclusion too quickly, that running your Next.js app as a Docker container is not an option.
In the end, it only displays how/where the feature related code is being executed. Your Next.js app, as a Docker container, is running just fine and does support all Next.js features.
Only when scaling your Docker based Next.js application you have to extend the default Next.js config to keep the full feature support. But read more on this at the self hosted Docker page.
If you are using a limited set of the Next.js features, you could as well just export your Next.js application as static HTML, CSS and Javascript.
Is static good enough?
Next.js Feature | Static Export | Node.js Server / Docker / Vercel / etc. |
---|---|---|
Client Components | ||
Server Components | ||
Image Optimization | ()1 | |
Route Handlers | ()2 | |
Dynamic Routes | ()3 | |
Middleware | ||
Caching and ISR | ||
Cookies | ||
Rewrites | ||
Redirects | ||
Headers | ||
Draft Mode | ||
Server Actions |
(1) You have to use a custom image loader or leave the images unoptimized
(2) Only GET requests are supported when using route handlers. The request will run during build and the payloads will turn into static files
(3) Only supported when using "generateStaticParams"
Running Next.js with the static export function basically turns Next.js into a static-site generator which then gives you an unlimited amount of options to deploy your application and makes it a cachable dream.