Update documentation related to the latest AWS Lambda runtime nodejs20.x

content/200-orm/200-prisma-client/500-deployment/201-serverless/400-deploy-to-aws-lambda.mdx

@@ -27,12 +27,27 @@ This section covers changes you will need to make to your application, regardles
 
 ### Define binary targets in Prisma Schema
 
-The Prisma schema should contain the following in the `generator` block:
+Depending on the version of Node.js, your Prisma schema should contain either `rhel-openssl-1.0.x` or `rhel-openssl-3.0.x` in the `generator` block:
+
+<TabbedContent tabs={['Node.js 16 and 18', 'Node.js 20+']}>
+
+<tab>
 
 ```prisma
 binaryTargets = ["native", "rhel-openssl-1.0.x"]
 ```
 
+</tab>
+<tab>
+
+```prisma
+binaryTargets = ["native", "rhel-openssl-3.0.x"]
+```
+
+</tab>
+
+</TabbedContent>
+
 This is necessary because the runtimes used in development and deployment differ. Add the [`binaryTarget`](/orm/reference/prisma-schema-reference#binarytargets-options) to make the compatible Prisma ORM engine file available.
 
 #### Lambda functions with arm64 architectures

content/200-orm/200-prisma-client/500-deployment/201-serverless/500-deploy-to-netlify.mdx

@@ -20,12 +20,27 @@ Before you can follow this guide, you will need to set up your application to be
 
 Since your code is being deployed to Netlify's environment, which isn't necessarily the same as your development environment, you will need to set [`binaryTargets`](/orm/reference/prisma-schema-reference#binarytargets-options) in order to download the query engine that is compatible with the Netlify runtime during your build step. If you do not set this option, your deployed code will have an incorrect query engine deployed with it and will not function.
 
-You should update your Prisma schema to contain the following in the `generator` block:
+Depending on the version of Node.js, your Prisma schema should contain either `rhel-openssl-1.0.x` or `rhel-openssl-3.0.x` in the `generator` block:
+
+<TabbedContent tabs={['Node.js 16 and 18', 'Node.js 20+']}>
+
+<tab>
 
 ```prisma
 binaryTargets = ["native", "rhel-openssl-1.0.x"]
 ```
 
+</tab>
+<tab>
+
+```prisma
+binaryTargets = ["native", "rhel-openssl-3.0.x"]
+```
+
+</tab>
+
+</TabbedContent>
+
 ## Store environment variables in Netlify
 
 We recommend keeping `.env` files in your `.gitignore` in order to prevent leakage of sensitives connection strings. Instead, you can use the Netlify CLI to [import values into netlify directly](https://docs.netlify.com/environment-variables/get-started/#import-variables-with-the-netlify-cli).

content/200-orm/200-prisma-client/500-deployment/650-caveats-when-deploying-to-aws-platforms.mdx

@@ -53,13 +53,15 @@ The [deployment package (.zip) size limit for lambdas is 50MB](https://docs.aws.
 Prisma CLI downloads additional engine binaries that are **not required** in production. You can delete the following files and folders:
 
 1. The entire `node_modules/@prisma/engines` folder (refer to the [sample bash script](https://github.com/prisma/ecosystem-tests/blob/13e74dc47eababa5d3c8f488b73fe7fc8bffead7/platforms-serverless/lambda/run.sh#L16) used by the Prisma end-to-end tests)
-2. The **local engine file** for your development platform from the `node_modules/.prisma/client` folder. For example, your schema might define the following `binaryTargets` if you develop on Debian (`native`) but deploy to AWS Lambda (`rhel-openssl-1.0.x`):
+2. The **local engine file** for your development platform from the `node_modules/.prisma/client` folder. For example, your schema might define the following `binaryTargets` if you develop on Debian (`native`) but deploy to AWS Lambda (`rhel-openssl-3.0.x`):
 
    ```prisma
-   binaryTargets = ["native", "rhel-openssl-1.0.x"]
+   binaryTargets = ["native", "rhel-openssl-3.0.x"]
    ```
 
    In this scenario:
 
-   - Keep `node_modules/.prisma/client/query-engine-rhel-openssl-1.0.x`, which is the engine file used by AWS Lambda
+   - Keep `node_modules/.prisma/client/query-engine-rhel-openssl-3.0.x`, which is the engine file used by AWS Lambda
    - Delete `node_modules/.prisma/client/query-engine-debian-openssl-1.1.x`, which is only required locally
+
+   > **Note**: When using Node.js 18 or earlier, the correct `binaryTarget` for AWS Lambda is `rhel-openssl-1.0.x`. `rhel-openssl-3.0.x` is the correct `binaryTarget` for Node.js versions greater than 18.

content/200-orm/500-reference/300-environment-variables-reference.mdx

@@ -270,10 +270,12 @@ The `PRISMA_FMT_BINARY` variable is used in versions [4.2.0](https://github.com/
 
 `PRISMA_CLI_BINARY_TARGETS` can be used to specify one or more binary targets that Prisma CLI will download during installation (so it must be provided during `npm install` of Prisma CLI and does not affect runtime of Prisma CLI or Prisma Client).
 
-Use `PRISMA_CLI_BINARY_TARGETS` if you 1) deploy to a specific platform via an upload of a local project that includes dependencies, and 2) your local environment is different from the target (e.g. AWS Lambda is `rhel-openssl-1.0.x`, and your local environment might be macOS arm64 `darwin-arm64`). Using the `PRISMA_CLI_BINARY_TARGETS` environment variable ensures that the target engine files are also downloaded.
+Use `PRISMA_CLI_BINARY_TARGETS` if you 1) deploy to a specific platform via an upload of a local project that includes dependencies, and 2) your local environment is different from the target (e.g. AWS Lambda with Node.js is `rhel-openssl-3.0.x`, and your local environment might be macOS arm64 `darwin-arm64`). Using the `PRISMA_CLI_BINARY_TARGETS` environment variable ensures that the target engine files are also downloaded.
 
 ```terminal
-PRISMA_CLI_BINARY_TARGETS=darwin-arm64,rhel-openssl-1.0.x npm install
+PRISMA_CLI_BINARY_TARGETS=darwin-arm64,rhel-openssl-3.0.x npm install
 ```
 
 This is the Prisma CLI equivalent for the [`binaryTargets` property of the `generator` block](/orm/prisma-schema/overview/generators#binary-targets), which enables you to define the same setting for Prisma Client.
+
+> **Note**: For Node.js versions earlier than 20, the openssl version was 1.0.x instead of 3.0.x. This is most obvious in AWS Lambda deployments, where the binary target would be `rhel-openssl-1.0.x` instead of `rhel-openssl-3.0.x`.