You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature- Container image (OCI) packaging support for Lambda Web Functions #103
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do * not help prioritize the request
If you are interested in providing additional feedback, please leave a comment
Description
Let you package and deploy Lambda Web Functions as OCI-compatible container images stored in Amazon Elastic Container Registry (Amazon ECR), in addition to .zip deployment packages. You would build your web application with your existing Dockerfile and container tooling, push the image to Amazon ECR, and reference it when you create a Web Function revision.
Additional context
Today, you package Web Function code as a .zip file in a versioned Amazon S3 bucket. The package must include your entry file and all dependencies, and the revision references the bucket, key, and object version.
Many teams already build and ship web applications as container images. They use multi-stage builds, scan images in their CI/CD pipelines, and need dependencies or system libraries that are easier to manage in a container. Lambda Event Functions support container images up to 10 GB.
Tell us how you would use this: your typical image size, whether you would start from an AWS-provided base image or your own, and which build and scanning tools you use. Please add details as comments.
Hello.
I’m the maintainer of the Swift runtime for AWS Lambda.
In the Swift server world, developers are using Swift to code their backend API, authorization functions, or event driven functions.
Before using Lambda, these developers typically created server side apps with one of the two popular web frameworks for Swift : Vapor and Hummingbird.
These frameworks provide developers with a web server and a routing mechanism to map HTTP verbs and paths to specific handler functions, just like express for node or flask for python.
Allowing these developers to deploy their code as is on a Lambda Web Function would significantly lower the barrier for adoption. They wouldn’t need to migrate their code from the handler functions in their framework to the Lambda runtime handler, they wouldn’t need to learn about API Gateway or function URL etc.
Typical base image is a minimal Ubuntu provided by Swift.org which adds the Swift toolchain (compiler and runtime libraries). Minimal size starts around 100mb and depends on the app dependencies.
Activity
sebsto commentedon Oct 21, 2026
Hello.
I’m the maintainer of the Swift runtime for AWS Lambda.
In the Swift server world, developers are using Swift to code their backend API, authorization functions, or event driven functions.
Before using Lambda, these developers typically created server side apps with one of the two popular web frameworks for Swift : Vapor and Hummingbird.
These frameworks provide developers with a web server and a routing mechanism to map HTTP verbs and paths to specific handler functions, just like express for node or flask for python.
Allowing these developers to deploy their code as is on a Lambda Web Function would significantly lower the barrier for adoption. They wouldn’t need to migrate their code from the handler functions in their framework to the Lambda runtime handler, they wouldn’t need to learn about API Gateway or function URL etc.
Typical base image is a minimal Ubuntu provided by Swift.org which adds the Swift toolchain (compiler and runtime libraries). Minimal size starts around 100mb and depends on the app dependencies.