aws-lambda-fastify is an MIT-licensed JavaScript library that runs a Fastify application as an AWS Lambda handler behind API Gateway or an Application Load Balancer, built for Node.js teams that already write HTTP APIs with Fastify and want to deploy them serverless without rewriting their routes.
What it is
The project is published as @fastify/aws-lambda and is inspired by the Code Genie serverless-express library, but tailor made for the Fastify web framework. It exports a single function, awsLambdaFastify(app), which takes a Fastify instance and returns a proxy that accepts a Lambda event and context and returns the response. That proxy is assigned directly to exports.handler, so the same Fastify application object can either listen on a port during local development or be exported as a module when it runs inside Lambda.
The concrete problem it solves is the adapter layer between Lambda's event-shaped invocation and a normal HTTP framework. A Fastify process inside Lambda does not need a listening socket or an exposed port, and this library avoids internal sockets entirely by dispatching through Fastify's own inject function. For Fastify users it replaces the generic serverless-express adapter and the separate aws-serverless-fastify project, both of which the README positions it against.
Key capabilities
- Install and import as
npm i @fastify/aws-lambda, then wrap an app with awsLambdaFastify(app, options).
- Request dispatch goes through Fastify's
inject function, so no internal socket is opened and no port is bound.
binaryMimeTypes lists Content-Type values such as application/octet-stream or image/png that should be base64-encoded for API Gateway.enforceBase64 accepts a custom (res) => boolean rule; when omitted, a built-in default base64-encodes any response carrying a non-identity Content-Encoding such as gzip, br, deflate or zstd.disableBase64Encoding suppresses base64 encoding and omits the isBase64Encoded property; it is enabled automatically when payloadAsStream is true and the request does not come from an ALB.serializeLambdaArguments writes the Lambda event and context into the x-apigateway-event and x-apigateway-context headers, and defaults to false.- The returned proxy works with several handler shapes:
exports.handler = proxy, (event, context, callback) => proxy(...), and async (event, context) => proxy(...).
Who uses it and how
- Node.js teams running Fastify APIs on AWS Lambda behind API Gateway, where the exported handler replaces a listening server entirely.
- Deployments fronted by an Application Load Balancer, since the base64 and streaming behaviour branches on whether the request arrives from an ALB.
- Projects migrating away from
serverless-express or aws-serverless-fastify that want to keep their Fastify routes, plugins and hooks unchanged.
- Services returning compressed or binary payloads, which rely on the
Content-Encoding-aware default or a custom enforceBase64 rule.
- Applications that need raw Lambda invocation data downstream, using
serializeLambdaArguments to surface event and context through request headers.
Getting started
Install with npm i @fastify/aws-lambda, then create a lambda.js that requires the library and the app, calls const proxy = awsLambdaFastify(app) and sets exports.handler = proxy. In app.js, export the Fastify instance when the file is required as a module and only call app.listen({ port: 3000 }) when it is run directly.
How it compares
The facts name two comparable tools: Code Genie's serverless-express, which inspired this library but targets Express-style frameworks, and aws-serverless-fastify, an earlier Fastify adapter. The README states that this project avoids internal sockets by using inject, and claims it seems faster than both of those alternatives, pointing to a basic performance metrics section rather than an independent benchmark.
When to use it — and when not to
Because it is a library rather than a service, a self-hoster operates nothing beyond the Lambda function itself: there is no database, storage bucket or SMTP configuration to run. Teams not using Fastify should not pick it, since the entire value comes from reusing a Fastify instance and its plugin ecosystem. The honest caveat is that the performance advantage is the README's own claim with basic metrics attached, the repository is small at 560 stars and 37 forks, and its documented surface is a short options table, so anyone needing deeper guarantees should read the source rather than rely on the README alone.
