Building Serverless Framework Images
A reusable Harness pipeline to build customized Serverless images.
This page provides a Harness CD pipeline to help you build your own Docker images for the Serverless framework.
The purpose of this pipeline is to give you flexibility—so you can adopt newer AWS Lambda runtimes or tailor the image to your specific serverless application needs.
What This Pipeline Does
This pipeline automates building Serverless images for different programming languages using Harness. It enables you to keep up with the latest Serverless versions and apply customizations as required for your projects.
You can find the full pipeline YAML in the Pipeline YAML section below.
Understanding Serverless Runtimes
Serverless runtimes refer to the programming language environments that the Serverless framework supports for function development. Each runtime provides the language-specific libraries, tools, and dependencies to build, test, and deploy serverless applications.
Common Serverless runtimes include:
Node.js: Versions like nodejs18.x, nodejs20.x, nodejs22.x
Python: Versions like python3.11, python3.12
Java: Versions like java8, java17, java21
Ruby: Versions like ruby2.7, ruby3.2
When you build your image using the Harness pipeline, you combine the Harness Serverless plugin (which provides the integration with Harness CD) with a specific runtime image from AWS. This allows you to deploy serverless applications written in your preferred programming language while leveraging Harness deployment capabilities.
Key Components and pre-requisites
This pipeline helps you build custom serverless plugin images using Harness, enabling integration of the Harness plugin with supported AWS Lambda runtimes. Below are the key details you should know about the pipeline:
Deployment Stage with Kubernetes Infrastructure
Utilizes a Deployment stage configured to run on Kubernetes.
Kubernetes Cluster Requirement and Privileged Mode
Requires a Kubernetes cluster set up by the user.
The pipeline’s step group runs with privileged: true mode enabled to allow Docker-in-Docker and image build operations.
This privileged mode requires the Kubernetes cluster nodes to permit privileged containers.
For example, if using Google Kubernetes Engine (GKE), do not use Autopilot clusters, as they restrict privileged containers. Instead, use a standard GKE cluster with node pools configured to allow privileged pods.
Connect the Kubernetes cluster to Harness via a Kubernetes Cluster connector.
Use of Official AWS SAM Images
Pulls SAM base images from the AWS ECR public gallery for compatibility.
Automatic Extraction of Runtime and Version
Extracts runtime name and version details directly from the SAM base image name.
Final Image Naming Convention
Images are named following the format:
serverless-plugin:{VERSION}-{RUNTIME_NAME}-{VERSION}-linux-amd64Example:serverless-plugin:1.1.0-beta-python3.12-1.1.0-beta-linux-amd64
Pipeline Runner Privileged Mode Requirement
Certain steps in the pipeline require the Kubernetes pod to run in privileged mode. This is necessary for starting Docker daemons (DinD), building container images inside pipeline steps, and granting the permissions Docker needs at runtime.
Why privileged mode is required:
Enables Docker-in-Docker (DinD) support for building and pushing images.
Allows installation and execution of docker CLI and manipulation of containers within the build step.
Required for root access and mounting Docker volumes.
To enable privileged execution, set privileged: true in the step group or step-level security context. Example:
For individual steps:
Without this setting, Docker builds and image pushes may fail due to insufficient permissions inside the container.
Quick Start
Copy and paste the pipeline YAML provided into your Harness Project.
Add an empty/do nothing service to the pipeline.
Add a Kubernetes environment to the pipeline.
In the Execution section, enable container-based execution in the step group. Add the Kubernetes cluster connector inside the container step group. Save the pipeline.
Click Run Pipeline
Enter the required parameters:
VERSION: The version number of the Harness base image (e.g.,
1.1.0-beta). VERSION represents specific code changes in the Harness repository. With each new code change, we push a new tag and publish new Docker images with these tags, allowing users to access specific versions of the plugin.Harness_base_image: You can find the Harness base image with the specific release versions from Harness DockerHub.
RUNTIME_BASE_IMAGE_VERSION: Runtime base image from AWS ECR (e.g.,
public.ecr.aws/sam/build-python3.12:1.142.1-20250701194731-x86_64)NODEJS_BASE_IMAGE_VERSION: Node.js base image from AWS ECR (e.g.,
public.ecr.aws/sam/build-nodejs20.x:1.142.1-20250701194712-x86_64)SERVERLESS_VERSION: Serverless Framework version (e.g.,
3.39.0)
Serverless Plugin Image Pre-requisites
The pipeline supports only complete formats for the base images:
public.ecr.aws/sam/build-java21:1.140.0-20250605234711-x86_64public.ecr.aws/sam/build-nodejs18.x:1.120.0-20240626164104-x86_64
Serverless Base Image Pre-requisites
Only official AWS SAM build images from the AWS ECR Public Gallery are supported.
Use SAM base images only from: AWS ECR Gallery - SAM
Only x86_64 architecture images are supported
Using different base images may cause library dependency issues
Non-standard base images may cause the plugin not to function as required
You must use the final image at the step level of your serverless deployment. This plugin cannot be used in Plugin info at the service level, as this setting at the service level fetches only from the Harness official Dockerhub repository.
Image Configuration
The pipeline produces two types of images with the following naming patterns:
Base Image (without Serverless Framework):
${RUNTIME_NAME}-${VERSION}-linux-amd64
Example: java21-1.1.0-beta-linux-amd64
Serverless Image (with Serverless Framework installed):
${RUNTIME_NAME}-${SERVERLESS_VERSION}-${VERSION}-linux-amd64
Example: java21-3.39.0-1.1.0-beta-linux-amd64
Where:
RUNTIME_NAME: Extracted runtime name (e.g.,java21,nodejs22.x)SERVERLESS_VERSION: Serverless Framework version (e.g.,3.39.0)VERSION: Harness plugin version (e.g.,1.1.0-beta)
Variables Used in Pipeline
These variables are actively used in the pipeline for building and pushing the image that you need to configure:
Pipeline variables: - TARGET_REPO, DOCKER_USERNAME, and DOCKER_PASSWORD are set once as pipeline-level variables.
TARGET_REPO
Target Docker repository to push built plugin images
your_account/serverless-plugin
Yes
DOCKER_USERNAME
Docker registry username
dockerhub_username
Yes
DOCKER_PASSWORD
Docker registry password or Personal Access Token (PAT)
<your_dockerhub_pat>
Yes
Runtime inputs: - VERSION, RUNTIME_BASE_IMAGE_VERSION, NODEJS_BASE_IMAGE_VERSION, HARNESS_BASE_IMAGE, and SERVERLESS_VERSION are user inputs set for each pipeline run to specify exact versions for the builds.
VERSION
Plugin image/version tag
1.1.2
Yes
RUNTIME_BASE_IMAGE_VERSION
AWS SAM runtime base image from ECR
public.ecr.aws/sam/build-python3.12:1.143.0-20250822194415-x86_64
Yes
NODEJS_BASE_IMAGE_VERSION
AWS SAM Node.js base image from ECR
public.ecr.aws/sam/build-nodejs22.x:1.143.0-20250822194415-x86_64
Yes
HARNESS_BASE_IMAGE
Harness base image used in build
harness/serverless-plugin:1.1.0-beta-base-image
Yes
SERVERLESS_VERSION
Serverless Framework version to install
3.39.0
Yes
Compatibility Validation
Runtime Compatibility: Always verify compatibility between runtime and Node.js images before building. The Serverless Framework requires Node.js to function correctly.
Library Dependencies: Check that both images share the same C++ libraries (especially
libstdc++.so) to ensure proper operation.
Validating Image Compatibility
Verify that the runtime and Node.js base images are compatible by sharing the same system libraries and dependencies. This is crucial because the Serverless Framework (which requires Node.js) must run properly on your chosen runtime image.
Step 1: Pull and Inspect Both Images
First, pull both images locally:
Step 2: Check C++ Library Compatibility
Check that both images have the same version of libstdc++.so:
They are compatible if both images show the same version (e.g., libstdc++.so.6.0.33).
Recommended Compatible Combinations
nodejs18.x
nodejs18.x
nodejs18.x
nodejs20.x
nodejs20.x
nodejs20.x
nodejs22.x
nodejs22.x
nodejs22.x
java17
nodejs18.x
java17
java21
nodejs22.x
java21
python3.11
nodejs18.x
python3.11
python3.12
nodejs20.x
python3.12
java8.al2
nodejs18.x
java8.al2
ruby3.2
nodejs18.x
ruby3.2
Pipeline YAML
This is the YAML for the AWS CDK image build pipeline. You can copy and paste it into your Harness Project.
This is how the stage would look in the UI:

Last updated
Was this helpful?