OpenNext for AWS: turning a Next.js build into Lambda packages

The gap OpenNext fills between next build and AWS

Next.js produces a build output that assumes a long-lived Node process. AWS Lambda gives you a function invocation. OpenNext sits in that gap: the README states it "takes the Next.js build output and converts it into packages that can be deployed across a variety of environments," with native support for AWS Lambda and a classic Node.js server. It does not replace Next.js, and it does not deploy anything by itself. It is a packaging step plus the runtime code that serves the packaged result.

The audience is narrow but real. If you are already committed to AWS and to Next.js, and you want App Router, server actions, ISR and image optimization to behave the way the framework documents them, this is the adapter aimed at that. If you are choosing a hosting platform from scratch, the project is the wrong entry point: the README points at SST as the maintainer, and the repository ships examples rather than a deployment product.

What the adapter actually does with your build output

The mechanism is a build-time transformation. You run the OpenNext CLI against a Next.js app that has already been built, and it emits deployable packages. The repository is a pnpm workspace with a `packages/` directory containing the adapter itself, a `docs/` site, and an `examples/` directory with `app-router`, `pages-router`, `app-pages-router`, `experimental` and `sst` variants. Those example names map onto the README's feature list: App and Pages Router, API routes, dynamic routes, SSG, SSR, ISR, middleware, server actions, image optimization and NextAuth.js.

Two runtime concerns are visible in the README. The first is cold starts. The project provides "a warmer function that can be used to reduce cold start," and the README is honest that warming is not a cure: on Lambda you still get a cold start when requests exceed warm instances, and because Next.js lazy loads routes, a warm instance may not have loaded the specific route being requested. The second is the edge target, which appears in the feature list as "Running at edge." Neither mechanism is described in detail in the README; the docs site is where the README sends you for configuration.

Installing OpenNext and running a first build

The README's contribution section is the closest thing to a local walkthrough, and it is written for people modifying OpenNext rather than for people consuming it. The published package is `@opennextjs/aws`, and the README also documents prerelease installs from `pkg.pr.new` for the `main` and `experimental` branches. The example it gives for that is a plain install of a URL:

npm i https://pkg.pr.new/@opennextjs/aws@main

That command installs the prerelease built from every push to `main`. The README calls it "the most up to date yet (reasonably) stable version of the package," which is a hedge worth reading literally: it is a branch build, not a tagged release. For anything you intend to keep running, the tagged npm package is the safer source.

Configuration is optional. The README states that you create `open-next.config.ts` next to your `next.config.js` and export a default object satisfying the `OpenNextConfig` interface, and that "it is possible to not have an open-next.config.ts file, the default configuration will then be applied automatically." So a first build needs no config file at all.

To run the CLI from a checkout of the repository, the README's steps are a pnpm build followed by a build of your own app against the local dist entry point:

cd packages/open-next
pnpm build

Then, from your Next.js app directory, the README shows invoking the built CLI directly:

cd path/to/my/nextjs/app
path/to/opennextjs-aws/packages/open-next/dist/index.js build

What you should see is a build that completes against the local OpenNext code instead of a published version. That is the loop the README describes for testing changes to the adapter itself, not the loop for deploying an application.

Debugging has one documented switch. Setting `OPEN_NEXT_DEBUG=true` before the build produces what the README calls "A LOT of additional logs," disables minifying in esbuild, and adds source maps. The README warns the result can be "up to 2-3X larger than the production build" and says not to enable it in production. That size figure is the project's own, and it is the kind of detail that tells you the flag is for local diagnosis only.

The cold start claim and its asterisk

The feature list includes "Almost no coldstart (*)" with a link to a Coldstart section, and that section is the most candid part of the README. It lists two scenarios where warming does not save you: more requests than warm instances, and Next.js lazy loading a route that a warm instance has not yet loaded. The warmer function reduces the problem; it does not remove it.

This matters for how you size a deployment. A workload with steady traffic and a small number of routes will sit inside the warm set most of the time. A workload with spiky traffic, or one where users hit deep dynamic routes rarely, will pay the lazy-load penalty on top of the instance penalty. The README does not publish latency numbers for either case, so treat the asterisk as an open question you answer with your own traffic, not as a solved problem.

Where OpenNext is the wrong tool

The README's own framing is the first limitation: OpenNext "aims to support all Next.js 15 features," and it says some features are work in progress. An adapter that tracks a moving framework will always lag somewhere. If your application depends on a Next.js feature that landed recently, the feature list is the thing to check before you commit, not after.

The second limitation is that this is an adapter, not a platform. There is no dashboard, no rollback story in the README, and no documented deployment command. The README sends you to the docs for configuration and to SST as the maintainer. If your team has no existing AWS deployment pipeline, OpenNext hands you a package and leaves the rest of the work where it was.

The third is debugging cost. The only diagnostic lever the README documents is `OPEN_NEXT_DEBUG=true`, and it inflates the build by 2-3X. That is a flag you turn on locally and off again, which means production issues are diagnosed against a different artifact than the one that failed. Teams that need to inspect what actually shipped will find that gap uncomfortable.

OpenNext against deploying Next.js by hand

The alternative most teams actually weigh is not a competing adapter but the manual route: run the Next.js standalone output on a container platform, or write your own Lambda handler around the server. That approach gives you full control over the runtime and no dependency on a third party tracking Next.js releases. It also means you reimplement the parts that are genuinely hard: ISR revalidation, image optimization, middleware execution and the lazy-loading behavior the README calls out.

The difference in approach is where the complexity lives. OpenNext puts it in a build step and a runtime package that the project maintains, and you inherit its release cadence. The manual route puts it in your codebase, and you inherit the maintenance. The README's acknowledgements name `nextjs-lambda`, `cdk-nextjs`, `serverless-http` and `serverless-nextjs` as prior art, which is a fair summary of how much work this category has historically required. The repository's `examples/sst` directory is the closest thing to an opinionated deployment path, and it points at the maintainer's own tooling rather than a neutral one.

Releases, licence and what upgrades cost you

The licence is MIT, declared both in the repository metadata and in the root `package.json`. That is permissive: you can use it commercially, modify it and ship it, provided you keep the licence notice. It is not legal advice, and the usual caveat applies that the adapter's output may incorporate Next.js code, whose own licence you should check separately.

Upgrade cost is visible in the release history. Three releases landed within about two weeks in September 2026 (v4.1.3, v4.1.4, v4.1.5), and the last push to the repository was on 2026-09-22. A cadence that tight on a patch line means the adapter is tracking something moving, most likely Next.js itself. Plan for periodic upgrades rather than a set-and-forget dependency, and pin a version in your lockfile so a rebuild does not silently change the runtime.

The repository is not archived, and the last push was on 2026-09-22. The root `package.json` requires Node 18 or later and pnpm 9 or later, with Turbo 1.10.12 and Biome 1.9.4 as build tooling, so a local checkout needs that toolchain before `pnpm build` will run.

Editorial conclusion

Adopt OpenNext if you already run Next.js on AWS infrastructure and want the framework's own output rather than a re-implementation of routing and rendering. Do not adopt it if you expect a managed control plane: the repository ships the adapter, examples and docs, and the README points to SST as the maintainer, so provisioning is your problem. Before committing, verify three things in this order: that your Next.js version is covered by the README's feature list, that your deployment tooling can consume the build output, and that a warmed Lambda is enough for your traffic pattern, since the README describes cold starts that survive a warm instance.

Frequently asked questions

Official sources

1. License: MIT
2. opennextjs/opennextjs-aws on GitHub
3. Project website
4. README
5. Releases