"No problem," I thought. This should be easy.

You can host a Next.js app on a server, and in many cases that’s the simplest option. Throw it on EC2. Maybe a container. Job done. But I knew the traffic for this particular site would be low and, more importantly, inconsistent. Keeping a server running 24/7 just to handle occasional bursts of traffic felt wasteful.

One of the main reasons developers choose Next.js is its hybrid model: static where possible, dynamic where necessary. It’s designed to adapt. Yet in practice, it seems that many deployments ignore that entirely, forcing it into a permanently running server.

It’s 2026. Serverless has come a long way. But if you’re not using Vercel, deploying Next.js this way still means stitching together undocumented integrations, handling edge cases, and dealing with implicit behaviour. Which is frustrating, because AWS already has everything you need: Lambda for compute, S3 for assets, CloudFront for distribution.

In theory, it’s a perfect fit.

In practice, it isn’t that simple.

The reality of “just use a platform”

Managed platforms like Vercel are popular for a reason: they abstract all of this work away. And to be clear, for small projects, prototypes, and even many production workloads, they’re hard to beat.

But in enterprise environments and large organisations, things look different.

You can’t always just adopt whatever platform works best on paper. There are constraints: procurement, governance, compliance, existing cloud strategy. And even if you do adopt a managed platform, you often end up needing more control as you scale, at which point you’re facing another replatforming, now under tighter SLAs and with real users depending on you.

That trade-off didn’t sit well with me.

When I looked into how others were solving this, most approaches fell into one of two camps:

• Run Next.js on a traditional server

• Use a managed platform that abstracts everything away

To me, both felt like giving up on what Next.js is actually capable of.

I also revisited AWS Amplify, which I’ve tried several times over the years. But it still feels like another managed platform with the same problems: limited control over the underlying resources, and trying to do so much in one suite that it becomes, ironically, despite its focus on developer experience, really difficult to use.

Discovering OpenNext

Then I came across OpenNext.

Finally, a community of people tackling the same problem: how to deploy Next.js outside of Vercel without losing its capabilities. The project provides an adapter that makes Next.js compatible with serverless platforms like AWS Lambda.

Since launching in 2023, it’s gained traction quickly, with backing from platforms like Cloudflare and Netlify. Today, thousands of sites rely on it to make their builds portable across different environments.

This was the first time things felt like they were heading in the right direction.

But there was still a gap.

The Terraform problem

I work heavily with Terraform. Not just AWS, but across multiple platforms, often in the same project. I might be provisioning Lambda functions alongside resources in Azure and Google Cloud, and I like that I can manage them from the same place.

These sorts of requirements are typical in environments where governance is tight, CI/CD is mature, and infrastructure needs to be transparent and auditable. So it was disappointing to see that the primary way to deploy OpenNext on AWS was through SST. It’s an awesome tool and does the job well for many projects, big and small. But not for this one.

Eventually, I found that NHS England had built a Terraform module for OpenNext. At first glance, it looked exactly like what I needed. But it hadn’t been maintained. The last release was in early 2024. Documentation was sparse, links were broken, and it didn’t work with current versions of the AWS provider.

I tried it anyway, and after several hours of bodging, I got it working. And from there, I kept going. Fixing bugs, improving the structure, writing proper documentation, and bringing it up to date with the latest OpenNext architecture.

Publishing it to the world

At some point, I realised that this would be useful for many projects. So, I got to work turning it into something reusable. And after 7 months of testing and iteration, this week I released it.

TerraNext is a free, open-source Terraform/OpenTofu module for deploying Next.js on AWS using a serverless architecture. It’s powered by OpenNext, but designed to feel native to Terraform workflows.

The goal is simple: let you run Next.js the way it was designed. It's serverless, scalable, and fully under your control. No black boxes. No hidden infrastructure.

And it's cheap. Really cheap.

Published under the MIT licence, you’re free to use it, modify it, and adapt it to your exact requirements. Thanks to its heavy use of cache policies and Lambda functions, you'll only need to pay for compute when you actually use it, or rather, when you want to use it. And of course, there's no 'per-seat' pricing, so you won't need to worry about paying up just to grow your team.

Oh, and that website I mentioned? It's now live in production at Centrica, serving thousands of users. I’m also using TerraNext for my personal site, as well as TerraNext’s own website.

What’s next

With the recent stable release of the Adapter API in Next.js 16.2, the ecosystem is finally catching up. The grip of vendor lock-in is starting to loosen, and we’re likely to see more demand for portable, infrastructure-native deployment approaches.

If you’re building with Next.js, working in AWS, and prefer Terraform, TerraNext might be worth a look.

https://terranext.dev