Next.js: You might want to use Vercel

TLDR: You might have read my previous article on deploying Next.js on Docker on AWS Elastic Beanstalk. This article is a follow-up.

In this one I go over some of the reasons why I migrated this blog from AWS Elastic Beanstalk over to Vercel. I give a (very) high-level overview of the deployment process on Vercel. If you are currently thinking about deploying your Next.js app on Elastic Beanstalk, this article might convince you to consider deploying to Vercel instead.

Spoiler: the whole migration to Vercel took ~5 minutes.

Next.js on AWS Elastic Beanstalk

Unlike traditional Single Page Applications (SPA), Next.js runs both server-side and client-side. That means that unless you are only using and exporting your Next.js as a static site that uses none of the Next.js backend features at all, you are going to need a server to run your Next.js app.

Running your Next.js site on Elastic Beanstalk is one step up from the poor man's setup consisting of running your app on a single EC2 instance provisioned manually. With Elastic Beanstalk, you get fancy goodies such as rolling deployments, automatic SSL certificate management with ACM if you are using an Elastic Load Balancer, basic logging, CLI tools that make CI/CD relatively painless, etc.

But we are still dealing with a fairly traditional setup that might not be particularly appropriate for your project.

Here are some of the issues you might run into running your Next.js project on Elastic Beanstalk:

• Speed - your requests are all going to be served by your EC2 instances located in whatever AWS Region they are located in. If you want to set up a CDN to cache static assets, you will need to set that up yourself.

• Costs - for a tiny personal blog running on Next.js, the costs are in the ballpark of US$30-40 a month for a setup with one or two small EC2 instances fronted with an ELB. You can get the costs down if you go with a deployment, but then you do not get much of the nice features of Elastic Beanstalk.

• Scaling - if you ever get a spike in traffic, your autoscaling group will need to scale out, that takes time and costs money.

• SSL termination - if you want to save money and go with a deployment without an ELB, you will have to manage the SSL certificate yourself and that involves crafting configuration files.

• EB platform version update - every once in a while the CLI commands might fail on you and tell you that you need to update the Elastic Beanstalk platform version your deployment is using. I ran into this a few weeks ago, my CI/CD would just fail, and since I was only using a single instance to save costs, it left my deployment broken until I updated the Docker version Elastic Beanstalk was using.

Next.js on Vercel

Vercel is the company behind Next.js. Their platform is tightly integrated with Next.js.

I was a little reticent to try out Vercel initially because serverless tooling can get super unwieldy and require billions of ever-changing configuration files. But there was no such headache with Vercel. The whole process was surprisingly clear and simple. If you compare it to AWS Amplify for example, it is night and day - Vercel does not try to do too much, but it does it right.

Some of the main goodies you get out of the box with Next.js Vercel are:

• CDN - your static assets are served through a global CDN automatically.

• SSL termination - Vercel abstracts away the SSL certificate management so you do not need to do anything about that.

• CI/CD - the way it works is you give Vercel access to your repository via their dashboard, then you configure a couple of settings (e.g. I want to deploy to ) and Vercel will automatically deploy for you.

• Analytics - the Vercel analytics give you insight into how your website is performing in terms of performance (e.g. First Contentful Paint, etc.).

• Per-branch preview - you can deploy previews of your commits before promoting the changes to production.

• Serverless backend - the routes under your directory will be automatically deployed as serverless functions (i.e. Lambda) that will scale up and down with load. You do not need to configure anything, the serverless setup is all abstracted away from you.

• It's free - it is all free if your use case falls within the Hobby plan.

Deploying to Vercel takes ~5 minutes

The process for me looked something like this:

• Sign up to Vercel
• At some point during the process, you are prompted to link up your GitHub and select a repository you want to deploy.
• It asks you for your build command () and your install command ().
• It deploys everything on its own and gives you a URL like
• It guides you through setting up DNS records to point your domain to the Vercel deployments.

Connecting to external infrastructure

If you are using external infrastructure on AWS in your routes, you will have to open the database security group to the Internet to let your Vercel deployment connect to it, which is not ideal.

Vercel uses dynamic IPs so it is not possible to whitelist specific IP ranges only, you will have to allow network access from the Internet. I assume that would even be a no-no for applications that require compliance, but to run your mom's recipe website or this blog, it is good enough.

For instance, say you are connecting to some database on AWS or something - you will probably want to set up Environment variables on your deployment. One minor annoyance to note is that some environment variable names such as are reserved - presumably because Vercel itself uses them.

To work around that, you might need to rename your standard AWS environment variables differently. For example, instead of , and you could name your environment variables , and (or whatever really) and configure your AWS SDK to use these names instead of implicitly reading the standard ones.

Here's what that might look like to connect to DynamoDB for example:

That's it.