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
tofalse
.
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.
Packaging Web services
Stacktape-image-buildpack (web-service)
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.
Copy
resources:webService:type: web-serviceproperties:packaging:type: stacktape-image-buildpackproperties:entryfilePath: src/main.tsresources:cpu: 2memory: 2048
External-buildpack (web-service)
- 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. - 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.
Copy
resources:webService:type: web-serviceproperties:packaging:type: external-buildpackproperties:sourceDirectoryPath: ./srcbuilder: heroku/buildpacks:20resources:cpu: 2memory: 2048
Custom-dockerfile (web-service)
- 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.
Copy
resources:webService:type: web-serviceproperties:packaging:type: custom-dockerfileproperties:buildContextPath: ./serverdockerfilePath: Dockerfileresources:cpu: 2memory: 2048
Prebuilt-image (web-service)
- 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.
Copy
resources:webService:type: web-serviceproperties:packaging:type: prebuilt-imageproperties:image: httpd:latestresources:cpu: 2memory: 2048
Packaging Private services
Stacktape-image-buildpack (private-service)
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.
Copy
resources:myPrivateService:type: private-serviceproperties:packaging:type: stacktape-image-buildpackproperties:entryfilePath: src/main.tsresources:cpu: 2memory: 2048
External-buildpack (private-service)
- 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. - 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.
Copy
resources:myPrivateService:type: private-serviceproperties:packaging:type: external-buildpackproperties:sourceDirectoryPath: ./srcbuilder: heroku/buildpacks:20resources:cpu: 2memory: 2048
Custom-dockerfile (private-service)
- 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.
Copy
resources:myPrivateService:type: private-serviceproperties:packaging:type: custom-dockerfileproperties:buildContextPath: ./serverdockerfilePath: Dockerfileresources:cpu: 2memory: 2048
Prebuilt-image (private-service)
- 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.
Copy
resources:myPrivateService:type: private-serviceproperties:packaging:type: prebuilt-imageproperties:image: httpd:latestresources:cpu: 2memory: 2048
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.
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. - 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.
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.
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.
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.
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. - 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.
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.
Prebuilt-image (batch-job)
- Pre-built image is used.
- The image must be publicly available.