Serverless services

Configure Serverless Lambda services in Harness, including manifest sources, artifact sources, and expression handling.

A Harness service for Serverless Lambda holds the serverless.yaml manifest and the deployment artifact (ZIP file or Docker image). Services are independent of pipelines; configure one once and reuse it across stages and pipelines.

---

What you will learn

• How to create a Serverless Lambda service in Harness.

• How to add manifest sources (Git, S3) to the service.

• How to add artifact sources (Artifactory, S3, ECR) to the service.

• How to use Go template expressions for containerized step manifests.

---

Before you begin

Ensure the following are in place before configuring a Serverless Lambda service:

• A connector to the repository or S3 bucket where your serverless.yaml is stored.

• A connector to the registry or bucket where your Lambda deployment artifact is stored.

---

Create a Serverless Lambda service

1. Go to Deployments, expand the drop-down, and select Services under Resources.

2. Select + New Service or + Create Service.

3. In the Create service panel, select Serverless Lambda from the Deployment Type drop-down.

4. Enter a name. Harness auto-generates the service ID from the name.

5. Under Storage, select Inline to have Harness store the service configuration, or select a Git repository.

6. Configure manifests and artifact sources as described in the sections below.

7. Select Save.

---

Add a manifest

Select + Add under Manifest and choose Serverless AWS Lambda. You can also add a separate Values YAML manifest alongside the primary manifest. Harness supports the following manifest sources.

Git sources

Use a Git source for serverless.yaml files stored in Harness Code, GitHub, Git, GitLab, Bitbucket, Azure Repos, or another Git provider.

The following fields are available when configuring a Git manifest source:

Field	Required	Description
ID	Yes	A unique identifier for this manifest within the service.
Connector	Yes	The connector to your Git provider.
Fetch	Yes	Select Branch to track a branch, Tag to pin a tag, or Commit to pin a specific commit SHA.
Branch / Tag / Commit	Yes	The branch name, tag, or commit SHA to fetch from.
Folder Path	Yes	The path from the repository root to the folder containing serverless.yaml.

Expand Advanced to set the Serverless Config File Path. By default, Harness searches the configured Folder Path for a file named serverless.yml, serverless.yaml, serverless.json, or serverlessDefaultStack.yml (checked in that order). If your manifest uses a different filename, enter the relative path to it here. This value is passed to the CLI as --config.

Amazon S3

Use this source for serverless.yaml files stored in an S3 bucket.

Field	Required	Description
ID	Yes	A unique identifier for this manifest within the service.
AWS Connector	Yes	A connector to your AWS account.
Region	Yes	The AWS region of the S3 bucket.
Bucket Name	Yes	The S3 bucket that contains your manifest files.
Folder Path	Yes	The path from the root of the bucket to the folder containing serverless.yaml.

ZIP files on S3

Harness supports .zip files on S3 as a manifest source. For containerized steps, the manifest must be at the root of the ZIP archive.

Manifest ID and container path

The ID you assign to each manifest determines where Harness places the fetched files inside the step container. Files land at /harness/<id>/<folder-path>/. For example, a manifest with ID m1 and Folder Path serverless2/ is placed at /harness/m1/serverless2/. The PLUGIN_WORK_DIR environment variable in the Deploy step resolves to this path. Use a meaningful ID to make log paths easier to read.

---

Add a Values YAML file

For containerized step deployments, Harness does not resolve expressions directly inside serverless.yaml. Instead, use Go template syntax in your manifest and supply a separate values.yaml file.

Expressions in manifests for containerized steps

If you place Harness expressions such as <+artifact.path> directly inside a serverless.yaml used with containerized steps, they are not resolved. The Serverless CLI receives the literal string and the deployment fails. Use Go template syntax with a values.yaml file instead.

In serverless.yaml, reference values using Go template syntax:

service: {{.Values.serviceName}}
frameworkVersion: "2 || 3"

provider:
  name: aws
  runtime: nodejs20.x

functions:
  hello:
    handler: handler.hello

package:
  artifact: {{.Values.artifactPath}}

In values.yaml, use Harness expressions freely:

serviceName: <+service.name>
artifactPath: <+artifact.path>

To add the values file:

1. Select + Add under Manifest.

2. Select Values YAML as the manifest type.

3. Assign a unique ID to this manifest entry (for example m2). This ID determines the file's location inside the container at /harness/<id>/<folder-path>/.

4. Configure the source connector, branch, and folder path to your values.yaml file.

Harness resolves the expressions in values.yaml first, then substitutes the resulting values into serverless.yaml before the Package step runs.

---

Add an artifact source

Select + Add under Artifacts and configure a Primary artifact. The following artifact types are supported.

Artifactory Registry

Use this source for ZIP files stored in JFrog Artifactory.

Field	Required	Description
ID	Yes	A unique identifier for this artifact source within the service.
Connector	Yes	A connector to your Artifactory instance.
Repository	Yes	The Artifactory repository name.
Artifact Directory	Yes	The directory path within the repository that contains the artifact.
Value / Regex	Yes	Select Value to specify a fixed artifact path, or Regex to match a pattern.
Artifact Path	Yes	The path to the ZIP file relative to the artifact directory, for example handler.zip.

Reference the artifact path in serverless.yaml with <+artifact.path> (non-containerized steps) or {{.Values.artifactPath}} (containerized steps).

Amazon S3

Use this source for ZIP files stored in an S3 bucket.

Field	Required	Description
ID	Yes	A unique identifier for this artifact source within the service.
AWS Connector	Yes	A connector to your AWS account.
Region	Yes	The AWS region of the S3 bucket.
Bucket Name	Yes	The S3 bucket that contains the artifact.
File Path	Yes	The path to the ZIP file within the bucket.

Amazon ECR

Use this source for Docker images stored in Amazon Elastic Container Registry.

Field	Required	Description
ID	Yes	A unique identifier for this artifact source within the service.
AWS Connector	Yes	A connector to your AWS account.
Region	Yes	The AWS region of the ECR registry.
Image Path	Yes	The full ECR repository path, for example 123456789.dkr.ecr.us-east-1.amazonaws.com/my-function.
Tag	Yes	The image tag to deploy. Supports runtime input.

Reference the image in serverless.yaml with <+artifact.image> (non-containerized steps) or {{.Values.image}} (containerized steps).

---

Limitations

Sidecar artifacts are not supported for containerized steps

The serverless-plugin container image processes only the primary artifact. If you add a sidecar artifact to the service and use containerized steps, the sidecar artifact is not downloaded and any sidecar expression in serverless.yaml is not resolved.

Sidecar artifacts work with non-containerized steps only. If you need to reference multiple artifacts, use non-containerized steps or combine all artifacts into the primary artifact.

---

Next steps

• Go to Serverless infrastructure to define your AWS deployment target.

• Go to Serverless deployment to configure execution steps and rollback.