sst/open-next

Open source Next.js serverless adapter

---

SST makes it easy to build modern full-stack applications on AWS. Watch the SST in 100 seconds video to learn more.

$ npx create-sst@latest

Pick your frontend

Deploy Next.js, Svelte, Remix, Astro, Solid, or any static site to AWS.

• Next.js
• Svelte
• Remix
• Astro
• Solid

Add any feature

SST gives you the full power of AWS. Making it easy to add any feature to your product.

• File uploads — Allow your users to upload files to S3.
• Auth — Authenticate your users through any auth provider.
• Events — Run tasks after your app has returned to your user.
• Databases — Use a serverless SQL or NoSQL database to power your app.
• Jobs — Run cron jobs or long running jobs powered by serverless functions.
• APIs — Add a dedicated serverless REST, GraphQL, or WebSocket API to your app.

Collaborate with your team

Finally, you can git push to deploy using SEED, a service built by the team behind SST. And you can work on your apps together with your team with automatic preview environments.

---

Join our community Discord | YouTube | Twitter | Contribute

open-next's Issues

Add `BUCKET_NAME` environment variable to instructions

We got caught with the Image Optimization Lambda needing the BUCKET_NAME environment variable to be set to the Assets S3 Bucket.

Can we update the docs to mention this value? Apart from that, it's been plain sailing :)

Do you have example Terraform, CloudFormation, SDK, or other infrastructure examples?

Hi. Do you have example Terraform, CloudFormation, SDK, or other infrastructure examples? Although I can build my own, I'd prefer to start with an example template.

Full support for ISR

Hello,

As of now it seems that ISR is not working as expected.
If the page is not found in the CDN (and cloudfront doesn't support stale-while-revalidate) it seems to work as if it was a SSR page.

I’ve found 2 possible solutions to this issue, but I’m not sure which one is the best :

• We could inject an incremental cache handler into the bundle during build using the experimental incrementalCacheHandlerPath config options (We need to disable minimalMode in NextServer).
• Create our own NextServer class that overrides getCacheFilesystem or getIncrementalCache and getResponseCache

I’d be happy to open a PR to solve this issue if I get some feedback from the maintainers or contributors.

The basePath breaks the OpenNext build.

By adding basePath to next.config.js breaks the build process.

I'm using the sst: 2.1.23 & next: 13.2.3

Bundling server function...
Bundling image optimization function...
Bundling middleware edge function...
file:///mac/.npm/_npx/a94ce00fc9d9ef90/node_modules/open-next/dist/build.js:196
    const src = buildOutput.output[middlewareName].files["index.js"].data;
                                                   ^
TypeError: Cannot read properties of undefined (reading 'files')
    at createMiddlewareBundle (file:///mac/.npm/_npx/a94ce00fc9d9ef90/node_modules/open-next/dist/build.js:196:52)
    at build (file:///mac/.npm/_npx/a94ce00fc9d9ef90/node_modules/open-next/dist/build.js:25:5)
Error: There was a problem building the "Site" StaticSite.

Trace: Error: There was a problem building the "Site" StaticSite.
    at NextjsSite.runBuild (file:///mac/nextjs-v13/node_modules/sst/constructs/SsrSite.js:252:19)
    at NextjsSite.buildApp (file:///mac/nextjs-v13/node_modules/sst/constructs/SsrSite.js:215:18)
    at new SsrSite (file:///mac/nextjs-v13/node_modules/sst/constructs/SsrSite.js:75:14)
    at new NextjsSite (file:///mac/nextjs-v13/node_modules/sst/constructs/NextjsSite.js:28:9)
    at EmptyStack.nextjs (/mac/nextjs-v13/sst.config.ts:9:16)
    at stack (file:///mac/nextjs-v13/node_modules/sst/constructs/FunctionalStack.js:20:35)
    at App.stack (file:///mac/nextjs-v13/node_modules/sst/constructs/App.js:489:16)
    at Object.stacks (/mac/nextjs-v13/sst.config.ts:28:9)
    at Module.synth (file:///mac/nextjs-v13/node_modules/sst/stacks/synth.js:54:20)
    at async Object.handler (file:///mac/nextjs-v13/node_modules/sst/cli/commands/build.js:9:20)
    at process.<anonymous> (file:///mac/nextjs-v13/node_modules/sst/cli/sst.js:58:17)
    at process.emit (node:events:539:35)
    at process.emit (node:domain:475:12)
    at process._fatalException (node:internal/process/execution:167:25)
    at processPromiseRejections (node:internal/process/promises:279:13)
    at processTicksAndRejections (node:internal/process/task_queues:97:32)

Api route failed to respond

Hi, the default api/hello route failed to respond when I deployed the server function to Lambda which works fine locally.
Any suggestions?

Better error handle from spawning next build

function buildNextjsApp(packager: "npm" | "yarn" | "pnpm") {
  cp.spawnSync(packager, packager === "npm" ? ["run", "build"] : ["build"], {
    stdio: "inherit",
    cwd: appPath,
  });
}

open-next should capture any errors and output it to the console.

eg:

const spawn =  cp.spawnSync(packager, packager === "npm" ? ["run", "build"] : ["build"], {
    stdio: "inherit",
    cwd: appPath,
  });

if (spawn.stderr) {
  console.log(Error(spawn.stderr))
  process.exitCode = 1;
}

Build failing if missing public directory

I was deploying a lot with SST yesterday via the NextjsSite construct and it was working fine. I started working on the project today and I was immediately getting the following error:

node:fs:1574
  handleErrorFromBinding(ctx);
  ^

Error: ENOENT: no such file or directory, lstat '/home/davidrhoderick/Development/martingale/vrio-pages/preview/public'
    at lstatSync (node:fs:1574:3)
    at statFunc (node:internal/fs/cp/cp-sync:122:15)
    at getStatsSync (node:internal/fs/cp/cp-sync:123:19)
    at checkPathsSync (node:internal/fs/cp/cp-sync:72:33)
    at cpSyncFn (node:internal/fs/cp/cp-sync:58:42)
    at Object.cpSync (node:fs:2904:3)
    at createAssets (file:///home/davidrhoderick/.npm/_npx/a94ce00fc9d9ef90/node_modules/open-next/dist/build.js:248:8)
    at build (file:///home/davidrhoderick/.npm/_npx/a94ce00fc9d9ef90/node_modules/open-next/dist/build.js:26:5) {
  errno: -2,
  syscall: 'lstat',
  code: 'ENOENT',
  path: '/home/davidrhoderick/Development/martingale/vrio-pages/preview/public'
}

Node.js v18.14.2
Error: There was a problem building the "Preview" StaticSite.

Trace: Error: There was a problem building the "Preview" StaticSite.
    at NextjsSite.runBuild (file:///home/davidrhoderick/Development/martingale/vrio-pages/node_modules/sst/constructs/SsrSite.js:252:19)
    at NextjsSite.buildApp (file:///home/davidrhoderick/Development/martingale/vrio-pages/node_modules/sst/constructs/SsrSite.js:215:18)
    at new SsrSite (file:///home/davidrhoderick/Development/martingale/vrio-pages/node_modules/sst/constructs/SsrSite.js:75:14)
    at new NextjsSite (file:///home/davidrhoderick/Development/martingale/vrio-pages/node_modules/sst/constructs/NextjsSite.js:28:9)
    at EmptyStack.PagesStack (/home/davidrhoderick/Development/martingale/vrio-pages/stacks/pages-stack.ts:57:19)
    at stack (file:///home/davidrhoderick/Development/martingale/vrio-pages/node_modules/sst/constructs/FunctionalStack.js:20:35)
    at App.stack (file:///home/davidrhoderick/Development/martingale/vrio-pages/node_modules/sst/constructs/App.js:489:16)
    at Object.stacks (/home/davidrhoderick/Development/martingale/vrio-pages/sst.config.ts:24:9)
    at Module.synth (file:///home/davidrhoderick/Development/martingale/vrio-pages/node_modules/sst/stacks/synth.js:54:20)
    at async file:///home/davidrhoderick/Development/martingale/vrio-pages/node_modules/sst/cli/commands/deploy.js:52:24
    at process.<anonymous> (file:///home/davidrhoderick/Development/martingale/vrio-pages/node_modules/sst/cli/sst.js:58:17)
    at process.emit (node:events:525:35)
    at process.emit (node:domain:489:12)
    at process._fatalException (node:internal/process/execution:149:25)
    at processPromiseRejections (node:internal/process/promises:288:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:96:32)

Once I added the public/ directory in my project, it passed. However, this is not ideal because I don't need an empty public/ directory and as I pass this project off to other team members, they would have to manually add an empty public/ directory as version control will not sync this folder without contents by default (maybe there's a way to hack that but either way, there's an issue with the Open Next build if it requires a folder that Next.js does not).

As I said, this is the NextjsSite construct, so it uses Open Next to build it via npx. At the time of this error, the version of Open Next used was 0.7.0.

Middleware is being executed on all resources

eg, /favicon is hitting the middleware edge lambda too, as well as all requests to the site.
This causes a 10-50ms latency and additional price penalty to each request.

We should read from the .next/server/middleware-manifest.json. One potential problem is that nextjs converts the matcher into a RegExp string... so we might have to read the config.matcher from the raw middleware.ts file.

Then we can create a new behavior w/ an exclusive edgeLambdas property.
eg:

 const middlewareBehavior = {
   ...serverBehavior,
   edgeLambas // move this out from the serverBehavior and put it here to isolate middleware requests
}

In the main Distribution:

additionalBehaviors: {
   ...
   [config.matcher[0]]: middlewareBehavior,
   [config.matcher[n]]: middlewareBehavior,
}

The default max cache behavior per distribution is 25. It should be easy to request a quota increase

AWS deployment strategies

Broadly speaking, without mentioning IaC options, this is what a release using open-next probably looks like in AWS infrastructure:

1. Merge master, trigger a new build
2. In the build, run open-next and derive the serverless functions from the source
3. Update current infrastructure with new serverless functions
   1. Image and server lambdas: tag them with the live alias after deploying new versions, so that the Lambda URL points to them.
   2. Middleware: add the new version to the viewer request on the default and the /_next/data/* CloudFront cache behavior, and that of course takes about 5 minutes.

This is roughly what I'm doing currently:

1. Run build and package the new functions for use with CloudFormation
2. Use CloudFormation to deploy new server, image optimization, and middleware functions.
3. Use a pipeline Lambda to update CloudFront cache behaviors for middleware.

Is this correct? Are there easier ways of doing this?

External image link failed

Hi, I build the next project and deployed on aws Lambda manually. But external image link failed with image optimized function.
The response is "fetch is not defined"

Any suggestions?

[feature/idea]: lambda response streaming

AWS just announced Lambda response streaming: https://aws.amazon.com/about-aws/whats-new/2023/04/aws-lambda-response-payload-streaming/

Curious if there is potential to leverage streams here.

Thanks again for this awesome project!

production concerns for critical project

since I found open-next, I've been very excited, and I really hope it continues to be maintained and grows more and more.

however, currently I've been seeing some bug reports that are a little worrying, and I'm about to start a next.js project where I intended to use this project.

in your opinion, is open-next ready for production?
should I know of something that isn't already in the documentation or that someone experienced differently than expected?

Support Streaming

AWS Lambda just introduced streaming capabilities via Lambda URLs. Opening this issue to gather some thoughts/interests from the community.

Ref:
https://beta.nextjs.org/docs/data-fetching/streaming-and-suspense
https://aws.amazon.com/blogs/compute/introducing-aws-lambda-response-streaming/

request for community feedback: multiple cloud providers considerations

I'm about to start a project where my client intends to use AWS, but together with another CDN provider (including considering another serverless provider, or mixed approach). this impacts directly on the open-next aspect.

Has anyone in the community tried to make use of different cloud services together with next.js and open-next and did it work? how was the setup?

p.s. I'm definitely not an expert on how next.js works in the background.

Provide support for yarn berry & pnpm

Hi, can you provide support for pnpm and yarn berry package managers?

@astore/[email protected] predeploy /home/ibra/accor/astore/packages/app
open-next build

node:internal/errors:477
ErrorCaptureStackTrace(err);
^

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@vercel/next' imported from /home/ibra/accor/astore/node_modules/.pnpm/[email protected]/node_modules/open-next/dist/build.js
at new NodeError (node:internal/errors:387:5)
at packageResolve (node:internal/modules/esm/resolve:951:9)
at moduleResolve (node:internal/modules/esm/resolve:1000:20)
at defaultResolve (node:internal/modules/esm/resolve:1214:11)
at nextResolve (node:internal/modules/esm/loader:165:28)
at ESMLoader.resolve (node:internal/modules/esm/loader:844:30)
at ESMLoader.getModuleJob (node:internal/modules/esm/loader:431:18)
at ModuleWrap. (node:internal/modules/esm/module_job:76:40)
at link (node:internal/modules/esm/module_job:75:36) {
code: 'ERR_MODULE_NOT_FOUND'
}

ServerFunction Lambda is importing modules that are only used in getStaticProps

I'm migrating an existing project that uses mainly getStaticProps for data fetching. In Vercel, the code inside getStaticProps only runs during build, and the lambda functions only import and store their dependencies. However, using open-next with sst, my lambda function is failing due to trying to run some code that should only be imported during build (inside getStaticProps).

Wrong file location for ".next" dir when used in monorepo

Hi guys, I've been actively using open-next in the last few days and I see the following problem:

When the next app is inside the packages folder in a monorepo structure, the ".next" folder is not correctly resolved when outputFileTracing is set to the monorepo's root:

The output file structure in the left , and the code loading ".next" on the right, we see clearly that it won't work because the .next folder is inside a different file structure.

Maybe doing something like:

// build.ts
// before  nextBuild

const { experimental } = require('./next.config.js')

const monorepoRootPrefix = experimental.outputFileTracingRoot ? path.relative(experimental.outputFileTracingRoot, appPath) : __dirname)

// then, on the server-function build:

const result = buildSync({
    entryPoints: [
      path.resolve(__dirname, "../assets/server-adapter.cjs")
    ],
    bundle: true,
    target: "node16",
    platform: "node",
    external: ["next", "aws-sdk"],
    outfile: path.join(outputPath, "index.cjs"),
    format: "cjs",
    define: {
       monorepoRootPrefix: JSON.stringify(monorepoRootPrefix)
    }
  });

// server-adapter.cjs
const nextDir = path.join(monorepoRootPrefix, ".next");

This way we could not only resolve monorepo root , but also hoisted node_modules at the level of the monorepo root .

In any case, when the app is far down inside a monorepo structure, the resolution of the next folder is not working well inside the lambda.

Building with latest version v.0.8.0 results in 502 errors. (attempting to read undefined properties in event)

Hello!

My very basic application was running fine on v.0.7.0. When I built via v.0.8.0 and deployed to AWS, it started returning 502 errors for every page. This is a example of the request (debug mode on OpenNext) and the resulting error.

From that error, it looks like it's trying to read event.requestContext.http.method, when that is not a property on the request I send from CloudFront. The part of code that error is pointing to is here:

I actually did try changing http.method to httpMethod, as the latter property is included in the request. But then, I would get an error that it could read length on rawQueryString (as that is undefined). From first glance, it seems like the CloudFront event I'm sending is being treated as an api gateway event.

Potentially something buggy here?

Thanks for reading! Feel free to ping me with any messages/clarifications. Would love to know if there's something super obvious I'm doing that's made this break between the v.0.7.0 and v.0.8.0 versions.

Question: How does app dir caching work?

Currently if you use the app dir feature of Nextjs 13, none of the "static" pages are cached.

The server-adapter has "loadHtmlPages()" that reads from .next/server/pages-manifest.json for /pages. In appDir, there is .next/routes-manifest.json that contains staticRoutes.

The problem w/ caching the appDir pages, eg: /hello, is that there are multiple requests to the same resource depending if it's rsc (prefetching). So you'd have to cache based off of the headers.
That is, the initial request to /hello loads the page while <Link href="/hello" /> will prefetch the page. These are two different requests under the same URL.

How do we get CloudFront to cache based off headers? I tried adding "rsc", "next-router-prefetch|state-tree" but that breaks CF => 503.

The prefetched resources have content-type: text/x-component

Middleware rewrite does not work

This issue was mentioned on discord and there is an open PR about it but I thought it would be good to open an issue to track it.
Basically middleware rewrite does not work when the nextjs site is deployed with sst.

To confirm this I forked open-next, added sst drop in mode to the example nextjs project and deployed it. Here is the deployed address for rewrite https://dooy830n0j9e.cloudfront.net/middleware-rewrite . The page does not work when accessed directly and is missing the check mark when you navigate to it. You can compare it to the deployed vercel one and see the green check mark https://open-next.vercel.app/middleware-rewrite

Here is the diff of me adding sst to the example main...mathisobadia:open-next:main. On a side note, I can open a PR to add it to the open-next example. It would be a good example of how to deploy with sst.

Issue deploying on AWS

Hi, nice project, I have some issues when deploying to lambda and using the reference archirtecture of the README.

When I configure an origin targeting the server lambda with the middleware one in the Viewer Request I get a 503 error, so I think I am missing something or there is some part of the documentation that I have not seen, is my configuration valid?

---

Configurations:

Origin Configuration:

Origin domain: [Server Lambda URL]
Origin Name: server-lambda
Protocol: https only

Behavior Configuration:

Path Pattern: Default (*)
Origin and origin groups: server-lambda
Viewer protocol policy: Redirect HTTP to HTTPS
Allowed HTTP methods: [GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE]
Cache key and origin requests:
  Cache policy: Cache Disabled
  Origin Request Policy: All viewer
Function associations:
  Viewer request: Lambda@Edge -> Middleware Lambda ARN
                              -> [x] Include Body

---

Errors

Cloudfront

The error I am are getting when I visit the CF distribution:

503 ERROR

The request could not be satisfied.

The Lambda function associated with the CloudFront distribution is invalid or doesn't have the required permissions. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.

Generated by cloudfront (CloudFront)
Request ID: [Redacted]

---

Thanks for any help.

Upgrading from v0.7.0 to v0.8.0 causing issues with next-auth

Upgrading from v0.7.0 to v0.8.0 is causing issues with all calls to our next-auth setup. The error we get is:

{
    "error": "[object Object]",
    "url": "/api/auth/session",
    "message": "Unexpected end of JSON input",
    "client": "true"
}

or

{
    "error": "[object Object]",
    "url": "/api/auth/providers",
    "message": "Unexpected end of JSON input",
    "client": "true"
}

We are using SST v2.4.0 to deploy and our next-auth version is v4.20.1
We are unsure exactly what change inside v.0.8 is breaking this for us, let me know if I can help with any more info

suggestion: add explanation about the disabled `compress` option of server-adapter to workarounds section

Hey, what's up everyone?!

Today, when the server-adapter creates a NextJS server, the open-next disables the compress option and in the code is mentioned a bug in the bundled compression package, this being the cause of the option being disabled.

https://github.com/serverless-stack/open-next/blob/265acefeaeac5511cee84089a71d79412a3aad21/src/adapters/server-adapter.ts#L22-L24

With this option disabled, the server don't compress rendered content causing a decrease performance in the network transfers between server to the client.

I would particularly like to see a better explanation and a possible recommendation to make a alternative solution about this in the Limitations and workarounds of readme, to turn this limitation of open-next more evident to other developers that want to use this lib.

[FR] Image Optimization Lambda: Allow for defining a bucket key prefix

Something like an environment variable like BUCKET_KEY_PREFIX that will make the function search on /process.env.BUCKET_KEY_PREFIX/... if defined.

This allows for more complex architectures and rollover of the public folder.

No support for *.cjs and *.mjs file extensions

First of all, thank you so much for the hard work on this library. This will help out so many companies in the future :)

I tried using the CLI locally, but ran into an error:

Error: next.config.js not found. Please make sure you are running this command inside a Next.js app.

However, I'm using Node 18 with the .cjs and .mjs file extensions to separate ESM and CJS file types. open-next only seems to pick up on the .js file-extension. (build.ts#L14)

Could you add support for both the .cjs and .mjs file extensions and types?

CloudFront error: Lambda@Edge does not support functions with an architecture of arm64

I was under the impression that the image optimization function was meant to be arm64?

`vercel-build` script is called if found in package.json

v0.8.0: node_modules in the server-function directory does not include all dependencies

Using Monorepo nextjs and SST. The server-function directory inside the .open-next folder does not contain the required node_modules. This results in a number of dependency issues when run on AWS Lambda. Reverting to 0.7.0 fixes the issue.

Error while being used as a child process

Hello guys,

I'm facing this issue while using the npx open-next build as a child process:

My code:

// ... 

console.log(chalk.green(`Code is located at: ${sitePath}`))

spawnSync('npx', ['open-next', 'build'], {
    cwd: sitePath,
    stdio: 'inherit',
    env: {
        ...process.env,
        NODE_OPTIONS: '--preserve-symlinks'
    }
})

Warning: Detected "engines": { "node": ">=16" } in your `package.json` that will automatically upgrade when a new major Node.js Version is released. Learn More: http://vercel.link/node-version
Detected `pnpm-lock.yaml` generated by pnpm 7...
WARNING: You should not upload the `.next` directory.
Installing dependencies...
Scope: all 17 workspace projects

../config postinstall$ yarn build
../config postinstall: yarn run v1.22.19
../config postinstall: warning package.json: No license field
../config postinstall: $ tsup
../config postinstall: Error [ERR_REQUIRE_ESM]: require() of ES Module /home/ibra/accor/astore/node_modules/.pnpm/node_modules/strip-final-newline/index.js from /home/ibra/accor/astore/node_modules/.pnpm/[email protected][email protected]/node_modules/execa/index.js not supported.
../config postinstall: Instead change the require of /home/ibra/accor/astore/node_modules/.pnpm/node_modules/strip-final-newline/index.js in /home/ibra/accor/astore/node_modules/.pnpm/[email protected][email protected]/node_modules/execa/index.js to a dynamic import() which is available in all CommonJS modules.
../config postinstall:     at Object.<anonymous> (/home/ibra/accor/astore/node_modules/.pnpm/[email protected][email protected]/node_modules/execa/index.js:5:27)
../config postinstall:     at Object.<anonymous> (/home/ibra/accor/astore/node_modules/.pnpm/[email protected][email protected]/node_modules/tsup/dist/index.js:1189:14)
../config postinstall:     at /home/ibra/accor/astore/node_modules/.pnpm/[email protected][email protected]/node_modules/tsup/dist/chunk-PDM6VDW3.js:170:58
../config postinstall:     at async CAC.<anonymous> (/home/ibra/accor/astore/node_modules/.pnpm/[email protected][email protected]/node_modules/tsup/dist/chunk-PDM6VDW3.js:170:23)
../config postinstall:     at async main (/home/ibra/accor/astore/node_modules/.pnpm/[email protected][email protected]/node_modules/tsup/dist/chunk-PDM6VDW3.js:223:3)
../config postinstall: error Command failed with exit code 1.
../config postinstall: info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
../config postinstall: Failed
 ELIFECYCLE  Command failed with exit code 1.
/home/ibra/accor/astore/node_modules/.pnpm/[email protected]/node_modules/@vercel/build-utils/dist/index.js:30916
            reject(new errors_1.NowBuildError({
                   ^

NowBuildError: Command "pnpm install" exited with 1
    at ChildProcess.<anonymous> (/home/ibra/accor/astore/node_modules/.pnpm/[email protected]/node_modules/@vercel/build-utils/dist/index.js:30916:20)
    at ChildProcess.emit (node:events:513:28)
    at ChildProcess.emit (node:domain:489:12)
    at maybeClose (node:internal/child_process:1093:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5) {
  hideStackTrace: true,
  code: 'BUILD_UTILS_SPAWN_1',
  link: undefined,
  action: undefined
}

Cannot find package esbuild @vercel/next @vercel/build-utils serverless-http

When running the command: npx open-next build
The following packages are missing:

• esbuild
• @vercel/next
• @vercel/build-utils
• serverless-http

The error for a missing package:

node:internal/errors:484
    ErrorCaptureStackTrace(err);
    ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'esbuild' imported from /Users/me/.npm/_npx/023205fa7f8910ff/node_modules/open-next/dist/build.js
 {
  code: 'ERR_MODULE_NOT_FOUND'
}

Installing them resolved this issue, but I suspect it needs to work without installing any other dependencies locally.

404 pages do not work

If you go to /a-page-that-does-not-exist, it won't render the Nextjs 404 Error page.
Instead, it'll show the AWS S3 Access Denied b/c of the origin group going to the Server, then falling back to S3.

I think we can remove the fallback ground altogether and put all static assets in a single path.
It's a compromise but one that makes sense imo.

runs 'yarn run build' during build

Not sure if this is a feature request or a question, but it would be awesome to be able to customize the yarn script that is run during the open-next build process.

My use case is I need to build other things and not just next during the build process but I need open next to build first.

Readme suggests that SST can be used to deploy

Hi,

After a couple of confusing hours trying out open-next with SST, I noticed that SST does not use open-next at all, the page linked in the readme points to https://docs.sst.dev/constructs/NextjsSite where you see they depend on serverless-next.js dependency @sls-next/lambda-at-edge.

Looking at the Builder class used it does not use anything from open-next, you are basically deploying a serverless-next.js wrapper using SST.

Can the reference to SST be removed from the Readme? It now indicates that you can use SST for deployment but in fact it has nothing to do with open-next.

Regards,

Error while building through : ```npx open-next build```

Bundling server function...
file:///home/ibra/accor/astore/node_modules/.pnpm/[email protected]/node_modules/open-next/dist/build.js:41
path.resolve(__dirname, "../assets/server-handler.js")
^

ReferenceError: __dirname is not defined
at createServerBundle (file:///home/ibra/accor/astore/node_modules/.pnpm/[email protected]/node_modules/open-next/dist/build.js:41:26)
at build (file:///home/ibra/accor/astore/node_modules/.pnpm/[email protected]/node_modules/open-next/dist/build.js:25:5)

Stale deployment pipeline

Hey folks,

I'm currently building a pipeline that goes through all the steps. The problem is that after bundling assets, it stales.
Anyone experienced the same?

Thanks

`NODE_ENV` is `undefined` in Lambda causing dependencies to run in development mode

Add a note to make sure to add the env NODE_ENV=production for performance reasons (not very significant) to lambda configuration.

Happy to contribute.

Copy / pasting code without attribution, breaking license!

@dougmoscrop's code is being copy/pasted here without attribution:

• https://github.com/serverless-stack/open-next/blob/main/packages/open-next/src/adapters/request.ts
• https://github.com/serverless-stack/open-next/blob/main/packages/open-next/src/adapters/response.ts

Original source:

• https://github.com/dougmoscrop/serverless-http/blob/master/lib/request.js
• https://github.com/dougmoscrop/serverless-http/blob/master/lib/response.js

Error on running build "TypeError: Cannot read properties of undefined"

I run npx open-next@latest build on a nextjs project and I get the error Bundling image optimization function... step

Bundling server function...
Bundling image optimization function...
file:///Users/awin/.npm/_npx/a94ce00fc9d9ef90/node_modules/open-next/dist/build.js:31
    createMiddlewareBundle(ret.output.middleware.files["index.js"].data);
                                                 ^

TypeError: Cannot read properties of undefined (reading 'files')
    at build (file:///Users/awin/.npm/_npx/a94ce00fc9d9ef90/node_modules/open-next/dist/build.js:31:50)

full error log at https://gist.github.com/awinabi/fb718f57bda3a9bbb451f02811931b42

I'm running the latest version of open-next.

Do I have to do some explicit config for the middleware functions?

Docs Request: Compare Average Latency & Cost

Hi, thank you for OpenNext! I have a question that I think many others will have and would be helpful to document. Given a medium sized app using Next.js, what is the average cold start using OpenNext? This is an important question because the promise of SSR is improved performance, but if using serverless degrades performances significantly, that may be a blocker for some development teams given latency requirements.

The cold start latency is a trade-off with cost, both runtime and operational. Serverless infrastructure is less expensive for run time cost for small-medium scale and is usually less expensive from an operational perspective (less complex). If a development team needs less latency than OpenNext but still want to build on AWS, what do they do? They could look to AWS AppRunner which enables container workloads implying less cold-starts while keeping small operational complexity. BUT, it'll likely be more expensive than serverless compute used by OpenNext. All this to say, it would be helpful to have comparison tables like:

Average Latency

Infrastructure	Small App	Medium App	Large App
OpenNext (Lambda & Lambda@Edge)	X ms	X ms	X ms
App Runner	X ms	X ms	X ms
Vercel	X ms	X ms	X ms
Other?	X ms	X ms	X ms

Cost

Infrastructure	Small App	Medium App	Large App
OpenNext (Lambda & Lambda@Edge)	$X	$X	$X
App Runner	$X	$X	$X
Vercel	$X	$X	$X
Other?	$X	$X	$X

Has anyone created a similar comparison? If you could share to benefit this project, that would be great!

Benchmark image optimization in arm64 Lambda function

Lars suggested that X86 might be faster for AVX2. We should test it out.
https://twitter.com/LarsFronius/status/1621203065478037504

Disable image optimization

I tried to disable the image optimization using this:

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  swcMinify: true,
  images: {
    unoptimized: true
  }
}

module.exports = nextConfig

But still I'm getting image-optimization-function folder.

If I don't want it, then how to implement it?

Cloudformation template

Trying to deploy Nextjs 13 using open-next with Serverless/Cloudformation.

Currently unsuccessful, but this is the start template I currently got, hope this could help some of you and can even help me debug it and make it work.

1. First of you will need the next 3 Serverless plugins to execute scripts, sync build to S3 and configure Lambda@Edge:

npm i --save @silvermine/serverless-plugin-cloudfront-lambda-edge serverless-s3-sync serverless-scriptable-plugin

2. Here is the full serverless config template file:

service: nextjs-app
useDotenv: true

plugins:
  - serverless-scriptable-plugin
  - serverless-s3-sync
  - '@silvermine/serverless-plugin-cloudfront-lambda-edge'

custom:
  scriptable:
    hooks:
      before:package:createDeploymentArtifacts:
        - npx open-next@latest build
        - mkdir -p ./.open-next/zips
        - cd .open-next/server-function && zip -r ../zips/server-function.zip .
        - cd .open-next/image-optimization-function && zip -r ../zips/image-optimization-function.zip .
  s3Sync:
    - bucketName: ${self:service}-assets
      localDir: .open-next/assets

package:
  individually: true

provider:
  name: aws
  runtime: nodejs16.x
  stage: ${opt:stage, 'dev'}
  region: us-east-1
  endpointType: REGIONAL
  apiGateway:
    shouldStartNameWithService: true
    binaryMediaTypes:
      - "*/*"

functions:
  default:
    description: Default Lambda for Next CloudFront distribution
    name: ${self:service}-${self:provider.stage}-default
    handler: index.handler
    runtime: nodejs16.x
    memorySize: 512
    timeout: 10
    package:
      artifact: .open-next/zips/server-function.zip
    lambdaAtEdge:
      - distribution: DefaultDistribution
        eventType: origin-request
        includeBody: true
      - distribution: DefaultDistribution
        eventType: origin-response
        includeBody: false
      - distribution: DefaultDistribution
        eventType: origin-request
        includeBody: true
        pathPattern: /api/*
      - distribution: DefaultDistribution
        eventType: origin-request
        includeBody: true
        pathPattern: /_next/data/*
      - distribution: DefaultDistribution
        eventType: origin-response
        includeBody: false
        pathPattern: /_next/data/*
  imageOptimization:
    description: Image Lambda for Next CloudFront distribution
    name: ${self:service}-${self:provider.stage}-image-optimization
    handler: index.handler
    runtime: nodejs16.x
    memorySize: 512
    timeout: 10
    package:
      artifact: .open-next/zips/image-optimization-function.zip
    lambdaAtEdge:
      - distribution: DefaultDistribution
        eventType: origin-request
        includeBody: true
        pathPattern: /_next/image

resources:
  Resources:
    DefaultDistribution:
      Type: AWS::CloudFront::Distribution
      Properties:
        DistributionConfig:
          Enabled: true
          PriceClass: PriceClass_All
          Origins:
            - DomainName: 'nextjs-app-assets.s3.us-east-1.amazonaws.com'
              Id: ${self:service}
              CustomOriginConfig:
                HTTPPort: '80'
                HTTPSPort: '443'
                OriginProtocolPolicy: http-only
          DefaultCacheBehavior:
            MinTTL: 0
            DefaultTTL: 0
            MaxTTL: 31536000
            TargetOriginId: ${self:service}
            ViewerProtocolPolicy: redirect-to-https
            AllowedMethods: [ 'GET', 'HEAD', 'OPTIONS' ]
            CachedMethods: [ 'HEAD', 'GET' ]
            Compress: true
            ForwardedValues:
              QueryString: true
              Headers:
                  - x-op-middleware-request-headers
                - x-op-middleware-response-headers
                - x-nextjs-data
                - x-middleware-prefetch
              Cookies:
                Forward: all
          CacheBehaviors:
            - TargetOriginId: ${self:service}
              ViewerProtocolPolicy: https-only
              PathPattern: /_next/static/*
              Compress: true
              AllowedMethods: [ 'GET', 'HEAD', 'OPTIONS' ]
              CachedMethods: [ 'HEAD', 'GET' ]
              ForwardedValues:
                QueryString: false
            - TargetOriginId: ${self:service}
              ViewerProtocolPolicy: https-only
              PathPattern: /api/*
              AllowedMethods: [ 'GET', 'HEAD', 'OPTIONS', 'PUT', 'POST', 'PATCH', 'DELETE' ]
              ForwardedValues:
                QueryString: true
                Cookies:
                  Forward: all
                Headers: [ 'Authorization', 'Host', 'Accept-Language' ]
            - TargetOriginId: ${self:service}
              ViewerProtocolPolicy: https-only
              PathPattern: /_next/image
              AllowedMethods: [ 'GET', 'HEAD', 'OPTIONS', 'PUT', 'POST', 'PATCH', 'DELETE' ]
              ForwardedValues:
                QueryString: false
                Headers: [ 'Accept' ]
            - TargetOriginId: ${self:service}
              ViewerProtocolPolicy: https-only
              PathPattern: /_next/data/*
              AllowedMethods: [ 'GET', 'HEAD' ]
              ForwardedValues:
                QueryString: true
                Cookies:
                  Forward: all
                Headers:
                  - x-op-middleware-request-headers
                  - x-op-middleware-response-headers
                  - x-nextjs-data
                  - x-middleware-prefetch

Suggested fallback for default behaviour causes 403

If a request is made for mysite.com/some/page/that/does/not/exist then NextJS will return a 404. The suggested fallback will then cause the request to be sent to S3. However, since there is nothing in S3 either (because the page doesn't exist) then S3 throws a 403.

I understand the theory behind the fallback, but this seems like a very poor tradeoff. Wondering whether anyone has found an elegant way to handle this that allows us to retain the NextJS 404 error page when somebody tries to visit a page that doesn't exist.

For the time being I have stopped redirecting 404s to the S3 origin.

What would the drawbacks be, if any, to switching the order such that we try to serve from S3 first and only try the lambda if S3 returns a 403? This is the only way I can think of that would end up with the 404 error being handled by NextJS.

Big fan of this project, and the long-form README has been an invaluable resource in getting this working. Thanks!

Infrastructure as code support

Hey OpenNext 👋🏻
Amazing project and thanks a lot for the effort !

I was wondering if you guys are planning to support Infra as code as part of the project, tools like Terraform (multi-cloud) can help create the AWS/GCP infrastructure for OpenNext as simple as running one command.

The terraform code will be in form of configuration code and it's mostly yaml-like files, I believe this will help users instantly create Lambdas, CloudFront CDNs etc, with the configuration required for OpenNext to run, a way to "Standarize" deployments.

Also Google Cloud users (& other clouds) will be able to deploy OpenNext infra too, so no Cloud Provider lock-in 😁

I offer to personally help with this task if you guys like the idea.

Thanks!

Build fails when using a src directory

When running open-next build, specifically when creating the middleware bundle, a src directory is never taken in to account.

https://github.com/serverless-stack/open-next/blob/1f57e3dbe6cdae1a101c9a75f148984ef5bd5aa0/src/build.ts#L187

Excerpt from next docs:

The src directory is very common in many apps and Next.js supports it by default.

So in my case the following would work:

const src: string = buildOutput.output['src/middleware'].files["index.js"].data;

But obviously both should be supported :)

Add support for geographic location in Middleware

Currently in the AWS setup, the middleware function run on viewer request. Unfortunately, CloudFront does not set geolocation headers for viewer request functions.

CloudFront adds the headers after the viewer request event, which means they are not available to Lambda@Edge in a viewer request function.

Alternative solution 1:

Run middleware on origin request. This means when the request is cached, middleware won't get run b/c origin request functions don't get called on cached content.

Alternative solution 2:

User 2 CloudFront distributions. Run middleware on origin request in the 1st distribution. And the origin for the 1st distribution points to the 2nd distribution. Downside is the added latency.

Suggestions welcome!

GCP Support

Hey, awesome project

Do you currently have any plan to support GCP? I find AWS's Lambda functions quite restrictive (size, runtime limits) compared to GCP's Cloud Functions / Cloud Run

I'm not sure what service could be used for the middleware, as I don't think GCP have a Lambda@Edge equivalent

Cheers

Server-function package too large for AWS Lambda function

Hello.

I'm trying to build and deploy our Next.js monorepo app with open-next to AWS Lambda and have some questions.

On dev environment zipped "server-function" took ~261 MB space, on production it more 5 times bigger. And it exceeds AWS limits. (AWS Lambda is limited by 50 MB zipped, for direct upload or 250 MB unzipped)

We are using Next.js v.12.2.2 and open-next@latest (0.5.2 at this moment). Without middleware for this time.

Do you have some workaround for such cases? Now we are using docker-mode hosting but it would be nice to migrate into serverless-mode.

Invalid path for export for server function on monorepo package in windows

In monorepo environment, open-next exports the real handler from dummy index.mjs. The path for the real handler is wrong in windows.

For following configuration, open-next fails to output correct path in windows:
Monorepo root: D:\my-app
App path: D:\my-app\packages\frontend

This outputs the index.mjs with following content:

export * from "./packages\frontend/index.mjs";

It should be

export * from "./packages/frontend/index.mjs";

Cannot read properties of undefined (reading 'x-op-middleware-request-headers')

Hey,

First of all let me thank you for this amazing package, its saved so much time for me in bundling this for lambda.

I am attempting to get this working with lambda@edge and am getting the message in the title when attempting to invoke the request from cloudfront.

Wondered if there were any insights into why this could be happening?

Thanks