[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-5529":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":25,"hasPages":23,"topics":26,"createdAt":10,"pushedAt":10,"updatedAt":27,"readmeContent":28,"aiSummary":29,"trendingCount":16,"starSnapshotCount":16,"syncStatus":17,"lastSyncTime":30,"discoverSource":31},5529,"llrt","awslabs\u002Fllrt","awslabs","LLRT (Low Latency Runtime) is an experimental, lightweight JavaScript runtime designed to address the growing demand for fast and efficient Serverless applications.","",null,"Rust",8747,395,45,44,0,2,6,15,7,38.79,"Apache License 2.0",false,"main",true,[],"2026-06-12 02:01:11","[![LLRT CI](https:\u002F\u002Fgithub.com\u002Fawslabs\u002Fllrt\u002Factions\u002Fworkflows\u002Fci.yml\u002Fbadge.svg?branch=main)](https:\u002F\u002Fgithub.com\u002Fawslabs\u002Fllrt\u002Factions\u002Fworkflows\u002Fci.yml) [![LLRT Release](https:\u002F\u002Fgithub.com\u002Fawslabs\u002Fllrt\u002Factions\u002Fworkflows\u002Frelease.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002Fawslabs\u002Fllrt\u002Factions\u002Fworkflows\u002Frelease.yml)\n\nLLRT (**L**ow **L**atency **R**un**t**ime) is a lightweight JavaScript runtime designed to address the growing demand for fast and efficient Serverless applications. LLRT offers up to over **10x** faster startup and up to **2x** overall lower cost compared to other JavaScript runtimes running on **AWS Lambda**\n\nIt's built in Rust, utilizing QuickJS as JavaScript engine, ensuring efficient memory usage and swift startup.\n\n> [!WARNING]\n> LLRT is an **experimental** package. It is subject to change and intended only for evaluation purposes.\n\n\u003Csub>LLRT - [DynamoDB Put, ARM, 128MB](example\u002Ffunctions\u002Fsrc\u002Fv3-lib.mjs):\u003Csub>\n![DynamoDB Put LLRT](.\u002Fbenchmarks\u002Fllrt-ddb-put.png \"LLRT DynamoDB Put\")\n\n\u003Csub>Node.js 20 - [DynamoDB Put, ARM, 128MB](example\u002Ffunctions\u002Fsrc\u002Fv3-lib.mjs):\u003Csub>\n![DynamoDB Put Node20](.\u002Fbenchmarks\u002Fnode20-ddb-put.png \"Node20 DynamoDB Put\")\n\nHTTP benchmarks measured in **round trip time** for a cold start ([why?](#benchmark-methodology))\n\n## Configure Lambda functions to use LLRT\n\nDownload the last LLRT release from \u003Chttps:\u002F\u002Fgithub.com\u002Fawslabs\u002Fllrt\u002Freleases>\n\n### Option 1: Custom runtime (recommended)\n\nChoose `Custom Runtime on Amazon Linux 2023` and package the LLRT `bootstrap` binary together with your JS code.\n\n### Option 2: Use a layer\n\nChoose `Custom Runtime on Amazon Linux 2023`, upload `llrt-lambda-arm64.zip` or `llrt-lambda-x64.zip` as a layer and add to your function\n\n### Option 3: Package LLRT in a container image\n\nSee our [AWS SAM example](.\u002Fexample\u002Fllrt-sam-container-image) or:\n\n```dockerfile\nFROM --platform=arm64 busybox\nWORKDIR \u002Fvar\u002Ftask\u002F\nCOPY app.mjs .\u002F\nADD https:\u002F\u002Fgithub.com\u002Fawslabs\u002Fllrt\u002Freleases\u002Flatest\u002Fdownload\u002Fllrt-container-arm64 \u002Fusr\u002Fbin\u002Fllrt\nRUN chmod +x \u002Fusr\u002Fbin\u002Fllrt\n\nENV LAMBDA_HANDLER \"app.handler\"\n\nCMD [ \"llrt\" ]\n```\n\n### Option 4: AWS SAM\n\nThe following [example project](example\u002Fllrt-sam\u002F) sets up a lambda\ninstrumented with a layer containing the llrt runtime.\n\n### Option 5: AWS CDK\n\nYou can use [`cdk-lambda-llrt` construct library](https:\u002F\u002Fgithub.com\u002Ftmokmss\u002Fcdk-lambda-llrt) to deploy LLRT Lambda functions with AWS CDK.\n\n```ts\nimport { LlrtFunction } from \"cdk-lambda-llrt\";\n\nconst handler = new LlrtFunction(this, \"Handler\", {\n entry: \"lambda\u002Findex.ts\",\n});\n```\n\nSee [Construct Hub](https:\u002F\u002Fconstructs.dev\u002Fpackages\u002Fcdk-lambda-llrt\u002F) and [its examples](https:\u002F\u002Fgithub.com\u002Ftmokmss\u002Fcdk-lambda-llrt\u002Ftree\u002Fmain\u002Fexample) for more details.\n\nThat's it 🎉\n\n> [!IMPORTANT]\n> Even though LLRT supports [ES2023](https:\u002F\u002F262.ecma-international.org\u002F14.0\u002F) it's **NOT** a drop in replacement for Node.js. Consult [Compatibility matrix](#compatibility-matrix) and [API](API.md) for more details.\n> All dependencies should be bundled for a `browser` platform and mark included `@aws-sdk` packages as external.\n\n## Testing & ensuring compatibility\n\nThe best way to ensure your code is compatible with LLRT is to write tests and execute them using the built-in test runner. The test runner currently supports Jest\u002FChai assertions. There are three main types of tests you can create:\n\nUnit Tests\n\n- Useful for validating specific modules and functions in isolation\n- Allow focused testing of individual components\n\nEnd-to-End (E2E) Tests\n\n- Validate overall compatibility with AWS SDK and WinterTC compliance\n- Test the integration between all components\n- Confirm expected behavior from end-user perspective\n- For more information about the E2E Tests and how to run them, see [here](tests\u002Fe2e\u002FREADME.md).\n\nWeb Platform Tests (WPT)\n\n- Useful for validating LLRT’s behavior against standardized browser APIs and runtime expectations\n- Ensure compatibility with web standards and cross-runtime environments\n- Help verify alignment with WinterTC and broader JavaScript ecosystem\n- For setup instructions and how to run WPT in LLRT, see [here](tests\u002Fwpt\u002FREADME.md).\n\n### Test runner\n\nTest runner uses a lightweight Jest-like API and supports Jest\u002FChai assertions. For examples on how to implement tests for LLRT see the `\u002Ftests` folder of this repository.\n\nTo run tests, execute the `llrt test` command. LLRT scans the current directory and sub-directories for files that ends with `*.test.js` or `*.test.mjs`. You can also provide a specific test directory to scan by using the `llrt test -d \u003Cdirectory>` option.\n\nThe test runner also has support for filters. Using filters is as simple as adding additional command line arguments, i.e: `llrt test crypto` will only run tests that match the filename containing `crypto`.\n\n## Compatibility matrix\n\n> [!NOTE]\n> LLRT only support a fraction of the Node.js APIs. It is **NOT** a drop in replacement for Node.js, nor will it ever be. Below is a high level overview of partially supported APIs and modules. For more details consult the [API](API.md) documentation\n\n| [Node.js API](https:\u002F\u002Fnodejs.org\u002Fapi\u002Findex.html) | Node.js | LLRT |\n| ------------------------------------------------ | ------- | ----- |\n| node:assert | ✔︎ | ✔︎️⚠️ |\n| node:async_hooks | ✔︎ | ✔︎️⚠️ |\n| node:buffer | ✔︎ | ✔︎️⚠️ |\n| node:child_process | ✔︎ | ✔︎⚠️ |\n| node:cluster | ✔︎ | ✘ |\n| node:console | ✔︎ | ✔︎⚠️ |\n| node:crypto | ✔︎ | ✔︎⚠️ |\n| node:dgram | ✔︎ | ✘ |\n| node:diagnostics_channel | ✔︎ | ✘ |\n| node:dns | ✔︎ | ✔︎⚠️ |\n| node:events | ✔︎ | ✔︎⚠️ |\n| node:fs | ✔︎ | ✔︎⚠️ |\n| node:fs\u002Fpromises | ✔︎ | ✔︎⚠️ |\n| node:http | ✔︎ | ✘⏱ |\n| node:http2 | ✔︎ | ✘ |\n| node:https | ✔︎ | ✘⏱ |\n| node:inspector | ✔︎ | ✘ |\n| node:inspector\u002Fpromises | ✔︎ | ✘ |\n| node:module | ✔︎ | ✔︎⚠️ |\n| node:net | ✔︎ | ✔︎⚠️ |\n| node:os | ✔︎ | ✔︎⚠️ |\n| node:path | ✔︎ | ✔︎⚠️ |\n| node:perf_hooks | ✔︎ | ✔︎⚠️ |\n| node:process | ✔︎ | ✔︎⚠️ |\n| node:querystring | ✔︎ | ✘ |\n| node:readline | ✔︎ | ✘ |\n| node:readline\u002Fpromises | ✔︎ | ✘ |\n| node:repl | ✔︎ | ✘ |\n| node:sqlite | ✔︎ | ✘ |\n| node:stream | ✔︎ | ✔︎\\* |\n| node:stream\u002Fpromises | ✔︎ | ✔︎\\* |\n| node:stream\u002Fweb | ✔︎ | ✔︎⚠️ |\n| node:string_decoder | ✔︎ | ✔︎ |\n| node:test | ✔︎ | ✘ |\n| node:timers | ✔︎ | ✔︎⚠️ |\n| node:tls | ✔︎ | ✘⏱ |\n| node:tty | ✔︎ | ✔︎⚠️ |\n| node:url | ✔︎ | ✔︎⚠️ |\n| node:util | ✔︎ | ✔︎⚠️ |\n| node:v8 | ✔︎ | ✘\\*\\* |\n| node:vm | ✔︎ | ✘ |\n| node:wasi | ✔︎ | ✘ |\n| node:worker_threads | ✔︎ | ✘ |\n| node:zlib | ✔︎ | ✔︎⚠️ |\n\n| [LLRT API](https:\u002F\u002Fgithub.com\u002Fawslabs\u002Fllrt\u002Fblob\u002Fmain\u002FAPI.md) | Node.js | LLRT |\n| ------------------------------------------------------------ | ------- | ---- |\n| llrt:hex | ✘ | ✔︎ |\n| llrt:qjs | ✘ | ✔︎ |\n| llrt:util | ✘ | ✔︎ |\n| llrt:xml | ✘ | ✔︎ |\n\n| [Web Platform API](https:\u002F\u002Fmin-common-api.proposal.wintertc.org\u002F) | LLRT |\n| ----------------------------------------------------------------- | ---- |\n| COMPRESSION | ✘⏱ |\n| CONSOLE | ✔︎⚠️ |\n| DOM | ✔︎⚠️ |\n| ECMASCRIPT | ✔︎⚠️ |\n| ENCODING | ✔︎⚠️ |\n| FETCH | ✔︎⚠️ |\n| FILEAPI | ✔︎⚠️ |\n| HR-TIME | ✔︎ |\n| HTML | ✔︎⚠️ |\n| STREAMS | ✔︎⚠️ |\n| URL | ✔︎ |\n| URLPATTERN | ✘⏱ |\n| WASM-JS-API-2 | ✘ |\n| WASM-WEB-API-2 | ✘ |\n| WEBCRYPTO | ✔︎⚠️ |\n| WEBIDL | ✔︎⚠️ |\n| XHR | ✔︎⚠️ |\n\n| Other features | LLRT |\n| -------------- | ---- |\n| async\u002Fawait | ✔︎ |\n| esm | ✔︎ |\n| cjs | ✔︎ |\n| Intl | ✔︎⚠️ |\n| Temporal | ✔︎⚠️ |\n\n_⚠️ = partially supported in LLRT_\u003Cbr \u002F>\n_⏱ = planned partial support_\u003Cbr \u002F>\n_\\* = Not native_\u003Cbr \u002F>\n_\\*\\* = The `module.registerHooks()` API allows you to emulate some functionality. See also `example\u002Fregister-hooks`._\u003Cbr \u002F>\n\n## Using node_modules (dependencies) with LLRT\n\nSince LLRT is meant for performance critical application it's not recommended to deploy `node_modules` without bundling, minification and tree-shaking.\n\nLLRT can work with any bundler of your choice. Below are some configurations for popular bundlers:\n\n> [!WARNING]\n> LLRT implements native modules that are largely compatible with the following external packages.\n> By implementing the following conversions in the bundler's alias function, your application may be faster, but we recommend that you test thoroughly as they are not fully compatible.\n\n| Node.js | LLRT |\n| --------------- | -------- |\n| fast-xml-parser | llrt:xml |\n\n### ESBuild\n\n```shell\nesbuild index.js --platform=browser --target=es2023 --format=esm --bundle --minify --external:@aws-sdk --external:@smithy\n```\n\n### Rollup\n\n```javascript\nimport resolve from \"@rollup\u002Fplugin-node-resolve\";\nimport commonjs from \"@rollup\u002Fplugin-commonjs\";\nimport terser from \"@rollup\u002Fplugin-terser\";\n\nexport default {\n input: \"index.js\",\n output: {\n file: \"dist\u002Fbundle.js\",\n format: \"esm\",\n sourcemap: true,\n target: \"es2023\",\n },\n plugins: [resolve(), commonjs(), terser()],\n external: [\"@aws-sdk\", \"@smithy\"],\n};\n```\n\n### Webpack\n\n```javascript\nimport TerserPlugin from \"terser-webpack-plugin\";\nimport nodeExternals from \"webpack-node-externals\";\n\nexport default {\n entry: \".\u002Findex.js\",\n output: {\n path: \"dist\",\n filename: \"bundle.js\",\n libraryTarget: \"module\",\n },\n target: \"web\",\n mode: \"production\",\n resolve: {\n extensions: [\".js\"],\n },\n externals: [nodeExternals(), \"@aws-sdk\", \"@smithy\"],\n optimization: {\n minimize: true,\n minimizer: [\n new TerserPlugin({\n terserOptions: {\n ecma: 2023,\n },\n }),\n ],\n },\n};\n```\n\n## Using AWS SDK (v3) with LLRT\n\nLLRT includes many AWS SDK clients and utils as part of the runtime, built into the executable. These SDK Clients have been specifically fine-tuned to offer best performance while not compromising on compatibility. LLRT replaces some JavaScript dependencies used by the AWS SDK by native ones such as Hash calculations and XML parsing.\nV3 SDK packages not included in the list below have to be bundled with your source code. For an example on how to use a non-included SDK, see [this example build script (buildExternalSdkFunction)](example\u002Ffunctions\u002Fbuild.mjs)\n\nLLRT supports the following three bundles by default. Bundle types and suffixes are as follows.\n\n| Bundle Type | Suffix | Purpose of Use |\n| ----------- | ----------- | --------------------------------------------------------- |\n| no-sdk | \\*-no-sdk | Suitable for workloads that do not use `@aws-sdk`. |\n| std-sdk | (none) | Suitable for workloads that utilize the major `@aws-sdk`. |\n| full-sdk | \\*-full-sdk | Suitable for workloads that utilize any `@aws-sdk`. |\n\nThe relationship between the supported packages for each bundle type is as follows.\n\n| Analytics | no-sdk | std-sdk | full-sdk |\n| ------------------------------------ | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-athena | | | ✔︎ |\n| @aws-sdk\u002Fclient-firehose | | | ✔︎ |\n| @aws-sdk\u002Fclient-glue | | | ✔︎ |\n| @aws-sdk\u002Fclient-kinesis | | | ✔︎ |\n| @aws-sdk\u002Fclient-opensearch | | | ✔︎ |\n| @aws-sdk\u002Fclient-opensearchserverless | | | ✔︎ |\n\n| Application integration | no-sdk | std-sdk | full-sdk |\n| --------------------------- | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-eventbridge | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fclient-scheduler | | | ✔︎ |\n| @aws-sdk\u002Fclient-sfn | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fclient-sns | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fclient-sqs | | ✔︎ | ✔︎ |\n\n| Business applications | no-sdk | std-sdk | full-sdk |\n| --------------------- | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-ses | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fclient-sesv2 | | | ✔︎ |\n\n| Compute services | no-sdk | std-sdk | full-sdk |\n| ---------------------------- | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-auto-scaling | | | ✔︎ |\n| @aws-sdk\u002Fclient-batch | | | ✔︎ |\n| @aws-sdk\u002Fclient-ec2 | | | ✔︎ |\n| @aws-sdk\u002Fclient-lambda | | | ✔︎ |\n\n| Containers | no-sdk | std-sdk | full-sdk |\n| -------------------------------- | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-ecr | | | ✔︎ |\n| @aws-sdk\u002Fclient-ecs | | | ✔︎ |\n| @aws-sdk\u002Fclient-eks | | | ✔︎ |\n| @aws-sdk\u002Fclient-servicediscovery | | | ✔︎ |\n\n| Databases | no-sdk | std-sdk | full-sdk |\n| -------------------------------- | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-dynamodb | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fclient-dynamodb-streams | | | ✔︎ |\n| @aws-sdk\u002Fclient-elasticache | | | ✔︎ |\n| @aws-sdk\u002Fclient-rds | | | ✔︎ |\n| @aws-sdk\u002Fclient-rds-data | | | ✔︎ |\n\n| Developer tools | no-sdk | std-sdk | full-sdk |\n| -------------------- | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-xray | | ✔︎ | ✔︎ |\n\n| Front-end web and mobile services | no-sdk | std-sdk | full-sdk |\n| --------------------------------- | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-amplify | | | ✔︎ |\n| @aws-sdk\u002Fclient-appsync | | | ✔︎ |\n| @aws-sdk\u002Fclient-location | | | ✔︎ |\n\n| Machine Learning (ML) and Artificial Intelligence (AI) | no-sdk | std-sdk | full-sdk |\n| ------------------------------------------------------ | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-bedrock | | | ✔︎ |\n| @aws-sdk\u002Fclient-bedrock-runtime | | | ✔︎ |\n| @aws-sdk\u002Fclient-bedrock-agent | | | ✔︎ |\n| @aws-sdk\u002Fclient-bedrock-agent-runtime | | | ✔︎ |\n| @aws-sdk\u002Fclient-polly | | | ✔︎ |\n| @aws-sdk\u002Fclient-rekognition | | | ✔︎ |\n| @aws-sdk\u002Fclient-textract | | | ✔︎ |\n| @aws-sdk\u002Fclient-translate | | | ✔︎ |\n\n| Management and governance | no-sdk | std-sdk | full-sdk |\n| --------------------------------- | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-appconfig | | | ✔︎ |\n| @aws-sdk\u002Fclient-appconfigdata | | | ✔︎ |\n| @aws-sdk\u002Fclient-cloudformation | | | ✔︎ |\n| @aws-sdk\u002Fclient-cloudwatch | | | ✔︎ |\n| @aws-sdk\u002Fclient-cloudwatch-events | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fclient-cloudwatch-logs | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fclient-service-catalog | | | ✔︎ |\n| @aws-sdk\u002Fclient-ssm | | ✔︎ | ✔︎ |\n\n| Media | no-sdk | std-sdk | full-sdk |\n| ---------------------------- | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-mediaconvert | | | ✔︎ |\n\n| Networking and content delivery | no-sdk | std-sdk | full-sdk |\n| ----------------------------------------- | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-api-gateway | | | ✔︎ |\n| @aws-sdk\u002Fclient-apigatewayv2 | | | ✔︎ |\n| @aws-sdk\u002Fclient-elastic-load-balancing-v2 | | | ✔︎ |\n\n| Security, identity, and compliance | no-sdk | std-sdk | full-sdk |\n| ----------------------------------------- | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-acm | | | ✔︎ |\n| @aws-sdk\u002Fclient-cognito-identity | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fclient-cognito-identity-provider | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fclient-iam | | | ✔︎ |\n| @aws-sdk\u002Fclient-kms | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fclient-secrets-manager | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fclient-sso | | | ✔︎ |\n| @aws-sdk\u002Fclient-sso-admin | | | ✔︎ |\n| @aws-sdk\u002Fclient-sso-oidc | | | ✔︎ |\n| @aws-sdk\u002Fclient-sts | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fclient-verifiedpermissions | | | ✔︎ |\n\n| Storage | no-sdk | std-sdk | full-sdk |\n| ------------------- | ------ | ------- | -------- |\n| @aws-sdk\u002Fclient-efs | | | ✔︎ |\n| @aws-sdk\u002Fclient-s3 | | ✔︎ | ✔︎ |\n\n| Other bundled packages | no-sdk | std-sdk | full-sdk |\n| -------------------------------- | ------ | ------- | -------- |\n| @aws-crypto | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fcredential-providers | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Flib-dynamodb | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Flib-storage | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fs3-presigned-post | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Fs3-request-presigner | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Futil-dynamodb | | ✔︎ | ✔︎ |\n| @aws-sdk\u002Futil-user-agent-browser | | ✔︎ | ✔︎ |\n| @smithy | | ✔︎ | ✔︎ |\n\n> [!TIP]\n> LLRT now supports streaming SDK responses (since version 0.9). You can consume response bodies as streams or use the convenience methods:\n>\n> ```javascript\n> const response = await client.send(command);\n>\n> \u002F\u002F Option 1: Stream the response body\n> for await (const chunk of response.Body) {\n> \u002F\u002F process chunk\n> }\n>\n> \u002F\u002F Option 2: Collect as string or bytes\n> const str = await response.Body.transformToString();\n> \u002F\u002F or\n> const bytes = await response.Body.transformToByteArray();\n> ```\n\n## Running TypeScript with LLRT\n\nSame principle as dependencies applies when using TypeScript. TypeScript must be bundled and transpiled into ES2023 JavaScript.\n\n> [!NOTE]\n> LLRT will not support running TypeScript without transpilation. This is by design for performance reasons. Transpiling requires CPU and memory that adds latency and cost during execution. This can be avoided if done ahead of time during deployment.\n\n## Rationale\n\nWhat justifies the introduction of another JavaScript runtime in light of existing options such as [Node.js](https:\u002F\u002Fnodejs.org\u002Fen), [Bun](https:\u002F\u002Fbun.sh) & [Deno](https:\u002F\u002Fdeno.com\u002F)?\n\nNode.js, Bun, and Deno represent highly proficient JavaScript runtimes. However, they are designed with general-purpose applications in mind. These runtimes were not specifically tailored for the demands of a Serverless environment, characterized by short-lived runtime instances. They each depend on a ([Just-In-Time compiler (JIT)](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FJust-in-time_compilation) for dynamic code compilation and optimization during execution. While JIT compilation offers substantial long-term performance advantages, it carries a computational and memory overhead.\n\nIn contrast, LLRT distinguishes itself by not incorporating a JIT compiler, a strategic decision that yields two significant advantages:\n\nA) JIT compilation is a notably sophisticated technological component, introducing increased system complexity and contributing substantially to the runtime's overall size.\n\nB) Without the JIT overhead, LLRT conserves both CPU and memory resources that can be more efficiently allocated to code execution tasks, thereby reducing application startup times.\n\n## Limitations\n\nThere are many cases where LLRT shows notable performance drawbacks compared with JIT-powered runtimes, such as large data processing, Monte Carlo simulations or performing tasks with hundreds of thousands or millions of iterations. LLRT is most effective when applied to smaller Serverless functions dedicated to tasks such as data transformation, real time processing, AWS service integrations, authorization, validation etc. It is designed to complement existing components rather than serve as a comprehensive replacement for everything. Notably, given its supported APIs are based on Node.js specification, transitioning back to alternative solutions requires minimal code adjustments.\n\n## Building from source\n\n1. Clone code and cd to directory\n\n```\ngit clone git@github.com:awslabs\u002Fllrt.git\ncd llrt\n```\n\n2. Install git submodules\n\n```\ngit submodule update --init --checkout\n```\n\n3. Install rust\n\n```\ncurl --proto '=https' --tlsv1.2 -sSf https:\u002F\u002Fsh.rustup.rs | bash -s -- -y\nsource \"$HOME\u002F.cargo\u002Fenv\"\n```\n\n4. Install dependencies\n\n```\n# MacOS\nbrew install zig make cmake zstd node corepack\n\n# Ubuntu\nsudo apt -y install make zstd\nsudo snap install zig --classic --beta\n\n# Windows WSL2 (requires systemd to be enabled*)\nsudo apt -y install cmake g++ gcc make zip zstd\nsudo snap install zig --classic --beta\n\n# Windows WSL2 (If Node.js is not yet installed)\nsudo curl -o- https:\u002F\u002Fraw.githubusercontent.com\u002Fnvm-sh\u002Fnvm\u002Fmaster\u002Finstall.sh | bash\nnvm install --lts\n```\n\n_\\* See [Microsoft Devblogs](https:\u002F\u002Fdevblogs.microsoft.com\u002Fcommandline\u002Fsystemd-support-is-now-available-in-wsl\u002F#how-can-you-get-systemd-on-your-machine)_\n\n5. Install Node.js packages\n\n```\ncorepack enable\nyarn\n```\n\n6. Install generate libs and setup rust targets & toolchains\n\n```\nmake stdlib && make libs\n```\n\n> [!NOTE]\n> If these commands exit with an error that says `can't cd to zstd\u002Flib`,\n> you've not cloned this repository recursively. Run `git submodule update --init` to download the submodules and run the commands above again.\n\n7. Build binaries for Lambda (Per bundle type and architecture desired)\n\n```\n# for arm64, use\nmake llrt-lambda-arm64.zip\nmake llrt-lambda-arm64-no-sdk.zip\nmake llrt-lambda-arm64-full-sdk.zip\n# or for x86-64, use\nmake llrt-lambda-x64.zip\nmake llrt-lambda-x64-no-sdk.zip\nmake llrt-lambda-x64-full-sdk.zip\n```\n\n8. Build binaries for Container (Per bundle type and architecture desired)\n\n```\n# for arm64, use\nmake llrt-container-arm64\nmake llrt-container-arm64-no-sdk\nmake llrt-container-arm64-full-sdk\n# or for x86-64, use\nmake llrt-container-x64\nmake llrt-container-x64-no-sdk\nmake llrt-container-x64-full-sdk\n```\n\n9. Optionally build for your local machine (Mac or Linux)\n\n```\nmake release\nmake release-no-sdk\nmake release-full-sdk\n```\n\nYou should now have a `llrt-lambda-arm64*.zip` or `llrt-lambda-x64*.zip`. You can manually upload this as a Lambda layer or use it via your Infrastructure-as-code pipeline\n\n## Crypto and TLS Backend Options\n\nLLRT supports multiple cryptographic backends for both the crypto module and TLS connections. These can be configured via Cargo features.\n\n### Crypto Provider Features\n\n| Feature | Description |\n| ----------------------- | ----------------------------------------------------------------- |\n| `crypto-rust` (default) | Pure Rust crypto using RustCrypto crates |\n| `crypto-ring` | Ring-only crypto (limited algorithm support) |\n| `crypto-ring-rust` | Ring for hashing\u002FHMAC, RustCrypto for everything else |\n| `crypto-graviola` | Graviola-only crypto (limited algorithm support) |\n| `crypto-graviola-rust` | Graviola for hashing\u002FHMAC\u002FAES-GCM, RustCrypto for everything else |\n| `crypto-openssl` | OpenSSL-based crypto |\n\n### TLS Backend Features\n\n| Feature | Description |\n| -------------------- | --------------------------------------------- |\n| `tls-ring` (default) | rustls with ring crypto |\n| `tls-aws-lc` | rustls with AWS-LC crypto (optimized for AWS) |\n| `tls-graviola` | rustls with graviola crypto |\n| `tls-openssl` | OpenSSL for TLS |\n\n### Building with Different Backends\n\n```bash\n# Default (crypto-rust + tls-ring)\ncargo build --release\n\n# Using AWS-LC for TLS\ncargo build --release --no-default-features --features \"macro,tls-aws-lc\"\n\n# Using OpenSSL for both crypto and TLS\ncargo build --release --no-default-features --features \"macro,crypto-openssl,tls-openssl\"\n\n# Using Graviola for both crypto and TLS\ncargo build --release --no-default-features --features \"macro,crypto-graviola-rust,tls-graviola\"\n```\n\n## Running Lambda emulator\n\nPlease note that in order to run the example you will need:\n\n- Valid AWS credentials via a `~\u002F.aws\u002Fcredentials` or via environment variables.\n\n```bash\nexport AWS_ACCESS_KEY_ID=XXX\nexport AWS_SECRET_ACCESS_KEY=YYY\nexport AWS_REGION=us-east-1\n```\n\n- A DynamoDB table (with `id` as the partition key) on `us-east-1`\n- The `dynamodb:PutItem` IAM permission on this table. You can use this policy (don't forget to modify \u003CYOUR_ACCOUNT_ID>):\n\n```json\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Sid\": \"putItem\",\n \"Effect\": \"Allow\",\n \"Action\": \"dynamodb:PutItem\",\n \"Resource\": \"arn:aws:dynamodb:us-east-1:\u003CYOUR_ACCOUNT_ID>:table\u002Fquickjs-table\"\n }\n ]\n}\n```\n\nStart the `lambda-server.js` in a separate terminal\n\n node lambda-server.js\n\nThen run llrt:\n\n make run\n\n## Environment Variables\n\n### `LLRT_ASYNC_HOOKS=value`\n\nWhen using asynchronous hooks, the hooking function inside QuickJS is activated. This is disabled by default as there is concern that it may have a significant impact on performance.\n\nBy setting this environment variable to `1`, the asynchronous hook function can be enabled, allowing you to track asynchronous processing using the `async_hooks` module.\n\n### `LLRT_EXTRA_CA_CERTS=file`\n\nLoad extra certificate authorities from a PEM encoded file\n\n### `LLRT_GC_THRESHOLD_MB=value`\n\nSet a memory threshold in MB for garbage collection. Default threshold is 20MB\n\n### `LLRT_HTTP_VERSION=value`\n\nExtends the HTTP request version. By default, only HTTP\u002F1.1 is enabled. Specifying '2' will enable HTTP\u002F1.1 and HTTP\u002F2.\n\n### `LLRT_LOG=[target][=][level][,...]`\n\nFilter the log output by target module, level, or both (using `=`). Log levels are case-insensitive and will also enable any higher priority logs.\n\nLog levels in descending priority order:\n\n- `Error`\n- `Warn | Warning`\n- `Info`\n- `Debug`\n- `Trace`\n\nExample filters:\n\n- `warn` will enable all warning and error logs\n- `llrt_core::vm=trace` will enable all logs in the `llrt_core::vm` module\n- `warn,llrt_core::vm=trace` will enable all logs in the `llrt_core::vm` module and all warning and error logs in other modules\n\n### `LLRT_NET_ALLOW=\"host[ ...]\"`\n\nSpace-delimited list of hosts or socket paths which should be allowed for network connections. Network connections will be denied for any host or socket path missing from this list. Set an empty list to deny all connections\n\n### `LLRT_NET_DENY=\"host[ ...]\"`\n\nSpace-delimited list of hosts or socket paths which should be denied for network connections\n\n### `LLRT_NET_POOL_IDLE_TIMEOUT=value`\n\nSet a timeout in seconds for idle sockets being kept-alive. Default timeout is 15 seconds\n\n### `LLRT_PLATFORM=value`\n\nUsed to explicitly specify a preferred platform for the Node.js package resolver. The default is `browser`. If `node` is specified, \"node\" takes precedence in the search path. If a value other than `browser` or `node` is specified, it will behave as if \"browser\" was specified.\n\n### `LLRT_REGISTER_HOOKS=file`\n\nIf you want to enable a hooking mechanism that is mostly compatible with Node.js's `module.registerHooks()`, specify the js file name in this environment variable.\n\nWe provide a concrete example in `example\u002Fregister-hooks`.\n\n> [!NOTE]\n> This environment variable is only effective when running on AWS Lambda.\n> When using the LLRT CLI, hook files must be specified using the --import option instead of this environment variable.\n\n### `LLRT_SDK_CONNECTION_WARMUP=1`\n\nInitializes TLS connections in parallel during function init which significantly reduces cold starts due. Enabled by default, can be disabled with value `0` or `false`\n\n### `LLRT_TLS_VERSION=value`\n\nSet the TLS version to be used for network connections. By default only TLS 1.2 is enabled. TLS 1.3 can also be enabled by setting this variable to `1.3`\n\n## Benchmark Methodology\n\nAlthough Init Duration [reported by Lambda](https:\u002F\u002Fdocs.aws.amazon.com\u002Flambda\u002Flatest\u002Fdg\u002Flambda-runtime-environment.html) is commonly used to understand cold start impact on overall request latency, this metric does not include the time needed to copy code into the Lambda sandbox.\n\nThe technical definition of Init Duration ([source](https:\u002F\u002Fdocs.aws.amazon.com\u002Flambda\u002Flatest\u002Fdg\u002Fnodejs-logging.html#node-logging-output)):\n\n> For the first request served, the amount of time it took the runtime to load the function and run code outside of the handler method.\n\nMeasuring round-trip request duration provides a more complete picture of user facing cold-start latency.\n\nLambda invocation results (λ-labeled row) report the sum total of Init Duration + Function Duration.\n\n## Security\n\nSee [CONTRIBUTING](CONTRIBUTING.md#security-issue-notifications) for more information.\n\n## License\n\nThis library is licensed under the Apache-2.0 License. See the [LICENSE](LICENSE) file.\n","LLRT (低延迟运行时) 是一个轻量级的JavaScript运行时，旨在满足对快速且高效的无服务器应用日益增长的需求。该项目使用Rust语言构建，并采用QuickJS作为JavaScript引擎，从而实现了更快的启动速度和更低的整体成本，在AWS Lambda上相比其他JavaScript运行时可提供高达10倍的启动速度提升以及总体成本降低至一半。LLRT特别适合需要极快响应时间的应用场景，例如实时数据处理、在线游戏逻辑处理等。尽管LLRT提供了显著的性能改进，但请注意它仍处于实验阶段，主要供评估目的使用，不建议直接替换现有的Node.js环境。","2026-06-11 03:03:48","top_language"]