Stacktape

Sign up



Packaging

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
handlerFunction
includeFiles
excludeFiles
excludeDependencies
languageSpecificConfig

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
handler

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
languageSpecificConfig
requiresGlibcBinaries
includeFiles
excludeFiles
excludeDependencies

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
builder
buildpack
command

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
entryPoint
dockerfilePath
buildArgs
command

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
repositoryCredentialsSecretArn
entryPoint
command

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
languageSpecificConfig
requiresGlibcBinaries
includeFiles
excludeFiles
excludeDependencies

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
builder
buildpack
command

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
dockerfilePath
buildArgs
command

Prebuilt-image (batch-job)

  • Pre-built image is used.
  • The image must be publicly available.
PrebuiltImageBjPackaging  API reference
image
Required
command

API reference

DockerBuildArg  API reference
argName
Required
value
Required
EsLanguageSpecificConfig  API reference
tsConfigPath
emitTsDecoratorMetadata
dependenciesToExcludeFromBundle
outputModuleFormat
Default: 'cjs'
Need help? Ask a question on SlackDiscord or info@stacktape.com.