PackagingWork in progress

Work in progress

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 to false.

StpBuildpackLambdaPackaging API reference

entryfilePath

Required

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

handlerFunction

The handler function (method) ran when the lambda function is invoked.

Type: string

includeFiles

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.

excludeFiles

Files that should be explicitly excluded from deployment package (glob pattern)

Type: Array of string

Example glob pattern: images/*.jpg

excludeDependencies

Dependencies to ignore.

Type: Array of string

These dependencies won't be a part of your deployment package.

languageSpecificConfig

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.

CustomArtifactLambdaPackaging API reference

packagePath

Required

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.

handler

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.

StpBuildpackCwImagePackaging API reference

entryfilePath

Required

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

languageSpecificConfig

Configuration of packaging properties specific to given language

Type: EsLanguageSpecificConfig

requiresGlibcBinaries

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.

includeFiles

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.

excludeFiles

Files that should be explicitly excluded from deployment package (glob pattern)

Type: Array of string

Example glob pattern: images/*.jpg

excludeDependencies

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 the buildpack 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.

ExternalBuildpackCwImagePackaging API reference

sourceDirectoryPath

Required

Path to the directory where the buildpack will be executed

Type: string

buildpack

Buildpack to use

Type: string

command

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 by dockerfilePath).
The image is uploaded to a pre-created (AWS ECR) container registry.

CustomDockerfileCwImagePackaging API reference

buildContextPath

Required

Path to directory (relative to stacktape config file) used as build context

Type: string

entryPoint

Script to be executed when the container starts. Overrides ENTRYPOINT instruction in the Dockerfile.

Type: Array of string

dockerfilePath

Path to Dockerfile (relative to buildContextPath) used to build application image.

Type: string

buildArgs

List of arguments passed to the docker build command when building the image

Type: Array of DockerBuildArg

command

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.

PrebuiltImageCwPackaging API reference

image

Required

Name or the URL of the image used in this workload.

Type: string

repositoryCredentialsSecretArn

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.

entryPoint

Script to be executed when the container starts. Overrides ENTRYPOINT instruction in the Dockerfile.

Type: Array of string

command

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.

StpBuildpackBjImagePackaging API reference

entryfilePath

Required

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

languageSpecificConfig

Configuration of packaging properties specific to given language

Type: EsLanguageSpecificConfig

requiresGlibcBinaries

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.

includeFiles

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.

excludeFiles

Files that should be explicitly excluded from deployment package (glob pattern)

Type: Array of string

Example glob pattern: images/*.jpg

excludeDependencies

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 the buildpack 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.

ExternalBuildpackBjImagePackaging API reference

sourceDirectoryPath

Required

Path to the directory where the buildpack will be executed

Type: string

buildpack

Buildpack to use

Type: string

command

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 by dockerfilePath).
The image is uploaded to a pre-created (AWS ECR) container registry.

CustomDockerfileBjImagePackaging API reference

buildContextPath

Required

Path to directory (relative to stacktape config file) used as build context

Type: string

dockerfilePath

Path to Dockerfile (relative to buildContextPath) used to build application image.

Type: string

buildArgs

List of arguments passed to the docker build command when building the image

Type: Array of DockerBuildArg

command

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.

PrebuiltImageBjPackaging API reference

image

Required

Name or the URL of the image used in this workload.

Type: string

command

Command to be executed when the container starts. Overrides CMD instruction in the Dockerfile.

Type: Array of string

Example: ['app.py']

API reference

DockerBuildArg API reference

argName

Required

Argument name

Type: string

value

Required

Argument value

Type: string

EsLanguageSpecificConfig API reference

tsConfigPath

Path to tsconfig.json file to use.

Type: string

This is used mostly to resolve path aliases.

emitTsDecoratorMetadata

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.

dependenciesToExcludeFromBundle

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.