Packaging Lambda functions
Stacktape-lambda-buildpack
Stacktape buildpack currently works only for Javascript and Typescript projects.
Built-in, zero-config, heavily optimized buildpack that creates a lambda artifact from an entryfile path.
Your source code is built into a single file with all of its external dependencies. This ensures you are shipping only the minimum required code. Behind the scenes, Stacktape uses esbuild.
Source-maps are automatically generated and includes in your deployment package. The generated code also includes the source map support library to make them usable.
If your dependency uses dynamic
require()
and can't be statically built, it will be copied as-is instead.If your dependency is dependent on a binary file, the dependency will be installed in a Docker container (based on the runtime used) and copied to the deployment package. This ensures your binary dependencies are usable even when deploying from a different OS (Windows or Mac).
Your deployment packages are cached. Stacktape creates a digest (checksum) from all the necessary files (and your package manager lockfiles). If a workload with the same digest is already deployed, the packaging and deployment is skipped.
Lambda function packages are zipped and uploaded to a pre-created S3 bucket.
The upload uses S3 transfer acceleration - upload is done to the nearest AWS's edge location, and then routed to the bucket using an Amazon backbone network. This is faster and more secure, but incurs additional transfer costs ($0.04 per GB). To disable this behavior, set
(config).deploymentConfig.useS3TransferAcceleration
tofalse
.
Path to the entry point of your workload (relative to the stacktape config file)
Type: string
- Stacktape tries to bundle all your source code with its dependencies into a single file.
- If a certain dependency doesn't support static bundling (because it depends on binary executable, uses dynamic require() calls, etc.), Stacktape will install it and copy it to the bundle
The handler function (method) ran when the lambda function is invoked.
Type: string
Files that should be explicitly included in the deployment package (glob pattern)
Type: Array of string
- Example glob pattern:
images/*.jpg
- The path is relative to the stacktape configuration file location or to
cwd
if configured using--currentWorkingDirectory
command line option.
Files that should be explicitly excluded from deployment package (glob pattern)
Type: Array of string
Example glob pattern: images/*.jpg
Dependencies to ignore.
Type: Array of string
- These dependencies won't be a part of your deployment package.
Configuration of packaging properties specific to given language
Type: EsLanguageSpecificConfig
Custom-artifact
- You supply a path to your own, pre-created artifact.
- If the specified path is a directory or an un-zipped file, Stacktape will zip it.
- The zipped lambda package is then uploaded to a pre-created S3 bucket using S3 transfer acceleration.
Path to the lambda package to use as the source for this lambda function
Type: string
- If the specified package path is a directory or an non-zip file, it will be automatically zipped.
The handler function (method) ran when the lambda function is invoked.
Type: string
- The syntax is
{{filepath}}:{{functionName}}
.
Packaging Container workloads
Stacktape-image-buildpack (container-workload)
Stacktape buildpack currently works only for Javascript and Typescript projects.
- Built-in, zero-config, heavily optimized buildpack that creates an image from an entryfile path.
- Your source code is built into a single file with all of its external dependencies. This ensures you are shipping only the minimum required code. Behind the scenes, Stacktape uses esbuild.
- Source-maps are automatically generated and includes in your deployment package. The generated code also includes the source map support library to make them usable.
- If your dependency uses dynamic
require()
and can't be statically built, it will be copied as-is instead. - If your dependency is dependent on a binary file, the dependency will be installed in a Docker container using a Docker multi-stage build.
- The base image used is the latest LTS version of node.js.
mhart/alpine-node:slim-16
in case your app doesn't require glibc-based binaries.node:16
in case it does.
- The image is uploaded to a pre-created (AWS ECR) container registry.
Path to the entry point of your workload (relative to the stacktape config file)
Type: string
- Stacktape tries to bundle all your source code with its dependencies into a single file.
- If a certain dependency doesn't support static bundling (because it depends on binary executable, uses dynamic require() calls, etc.), Stacktape will install it and copy it to the bundle
Configuration of packaging properties specific to given language
Type: EsLanguageSpecificConfig
Builds image with support for glibc-based binaries
Type: boolean
- You can use this option to add support for glibc-based native dependencies.
- This means that Stacktape will use different (and significantly larger) base-image for your container.
- Stacktape uses alpine Docker images by default. These images use musl, instead of glibc.
- Packages with C-based binaries compiled using glibc doesn't work with musl.
Files that should be explicitly included in the deployment package (glob pattern)
Type: Array of string
- Example glob pattern:
images/*.jpg
- The path is relative to the stacktape configuration file location or to
cwd
if configured using--currentWorkingDirectory
command line option.
Files that should be explicitly excluded from deployment package (glob pattern)
Type: Array of string
Example glob pattern: images/*.jpg
Dependencies to ignore.
Type: Array of string
- These dependencies won't be a part of your deployment package.
External-buildpack (container-workload)
- The image is built using a zero-config external buildpack.
- You can find a buildpack for almost any language or framework. The default buildpack used is
paketobuildpacks/builder:base
. You can configure the buildpack used by specifying thebuildpack
property. To show a list of available buildpacks for a given language/framework combination, you can use the buildpack:suggest command. - The buildpack works by scanning the specified source directory and automatically determining how the build the image for a given application.
- The image is uploaded to a pre-created (AWS ECR) container registry.
Path to the directory where the buildpack will be executed
Type: string
Buildpack to use
Type: string
Command to be executed when the container starts.
Type: Array of string
- Example:
['app.py']
.
Custom-dockerfile (container-workload)
- The image is built from your own Dockerfile.
- You need to configure
buildContextPath
. Stacktape will look for a Dockerfile in this directory (or use a Dockerfile specified bydockerfilePath
). - The image is uploaded to a pre-created (AWS ECR) container registry.
Path to directory (relative to stacktape config file) used as build context
Type: string
Script to be executed when the container starts. Overrides ENTRYPOINT instruction in the Dockerfile.
Type: Array of string
Path to Dockerfile (relative to buildContextPath
) used to build application image.
Type: string
List of arguments passed to the docker build
command when building the image
Type: Array of DockerBuildArg
Command to be executed when the container starts. Overrides CMD instruction in the Dockerfile.
Type: Array of string
- Example:
['app.py']
Prebuilt-image (container-workload)
- Pre-built image is used.
- To use private images, you need to configure
repositoryCredentialsSecretArn
. The body of the secret should have the following format:{"username" : "<<privateRegistryUsername>>", "password" : "<<privateRegistryPassword>>"}
. Secrets can be managed directly using Stacktape. For more information, refer to secrets docs.
Name or the URL of the image used in this workload.
Type: string
ARN (Amazon resource name) of the secret containing credentials for the private registry containing the image.
Type: string
- The body of the secret should have the following format:
{"username" : "<
>", "password" : "< >"} - Secrets can be managed directly using Stacktape. For more information, refer to secrets docs.
Script to be executed when the container starts. Overrides ENTRYPOINT instruction in the Dockerfile.
Type: Array of string
Command to be executed when the container starts. Overrides CMD instruction in the Dockerfile.
Type: Array of string
- Example:
['app.py']
Packaging Batch jobs
Stacktape-image-buildpack (batch-job)
Stacktape buildpack currently works only for Javascript and Typescript projects.
- Built-in, zero-config, heavily optimized buildpack that creates an image from an entryfile path.
- Your source code is built into a single file with all of its external dependencies. This ensures you are shipping only the minimum required code. Behind the scenes, Stacktape uses esbuild.
- Source-maps are automatically generated and includes in your deployment package. The generated code also includes the source map support library to make them usable.
- If your dependency uses dynamic
require()
and can't be statically built, it will be copied as-is instead. - If your dependency is dependent on a binary file, the dependency will be installed in a Docker container using a Docker multi-stage build.
- The base image used is the latest LTS version of node.js.
mhart/alpine-node:slim-16
in case your app doesn't require glibc-based binaries.node:16
in case it does.
- The image is uploaded to a pre-created (AWS ECR) container registry.
Path to the entry point of your workload (relative to the stacktape config file)
Type: string
- Stacktape tries to bundle all your source code with its dependencies into a single file.
- If a certain dependency doesn't support static bundling (because it depends on binary executable, uses dynamic require() calls, etc.), Stacktape will install it and copy it to the bundle
Configuration of packaging properties specific to given language
Type: EsLanguageSpecificConfig
Builds image with support for glibc-based binaries
Type: boolean
- You can use this option to add support for glibc-based native dependencies.
- This means that Stacktape will use different (and significantly larger) base-image for your container.
- Stacktape uses alpine Docker images by default. These images use musl, instead of glibc.
- Packages with C-based binaries compiled using glibc doesn't work with musl.
Files that should be explicitly included in the deployment package (glob pattern)
Type: Array of string
- Example glob pattern:
images/*.jpg
- The path is relative to the stacktape configuration file location or to
cwd
if configured using--currentWorkingDirectory
command line option.
Files that should be explicitly excluded from deployment package (glob pattern)
Type: Array of string
Example glob pattern: images/*.jpg
Dependencies to ignore.
Type: Array of string
- These dependencies won't be a part of your deployment package.
External-buildpack (batch-job)
- The image is built using a zero-config external buildpack.
- You can find a buildpack for almost any language or framework. The default buildpack used is
paketobuildpacks/builder:base
. You can configure the buildpack used by specifying thebuildpack
property. To show a list of available buildpacks for a given language/framework combination, you can use the buildpack:suggest command. - The buildpack works by scanning the specified source directory and automatically determining how the build the image for a given application.
- The image is uploaded to a pre-created (AWS ECR) container registry.
Path to the directory where the buildpack will be executed
Type: string
Buildpack to use
Type: string
Command to be executed when the container starts.
Type: Array of string
- Example:
['app.py']
.
Custom-dockerfile (batch-job)
- The image is built from a specified Dockerfile.
- You need to configure
buildContextPath
. Stacktape will look for a Dockerfile in this directory (or use a Dockerfile specified bydockerfilePath
). - The image is uploaded to a pre-created (AWS ECR) container registry.
Path to directory (relative to stacktape config file) used as build context
Type: string
Path to Dockerfile (relative to buildContextPath
) used to build application image.
Type: string
List of arguments passed to the docker build
command when building the image
Type: Array of DockerBuildArg
Command to be executed when the container starts. Overrides CMD instruction in the Dockerfile.
Type: Array of string
- Example:
['app.py']
Prebuilt-image (batch-job)
- Pre-built image is used.
- The image must be publicly available.
Name or the URL of the image used in this workload.
Type: string
Command to be executed when the container starts. Overrides CMD instruction in the Dockerfile.
Type: Array of string
- Example:
['app.py']
API reference
Argument name
Type: string
Argument value
Type: string
Path to tsconfig.json file to use.
Type: string
This is used mostly to resolve path aliases.
Emits decorator metadata to the final bundle.
Type: boolean
- This is used by frameworks like NestJS or ORMs like TypeORM.
- This is not turned on by default, because it can slow down the build process.
Dependencies to exclude from main bundle.
Type: Array of string
- These dependencies will be treated as
external
and won't be statically built into the main bundle. - Instead, they will be installed and copied to the deployment package.
- Using
*
means all of the workload's dependencies will be treated as external.