> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/3.0/use-deployments/overview-2/serverless-services.md).

# 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 <a href="#what-you-will-learn" id="what-you-will-learn"></a>

* 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 <a href="#git-sources" id="git-sources"></a>

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 <a href="#amazon-s3" id="amazon-s3"></a>

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`. |

{% hint style="info" %}
**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.
{% endhint %}

{% hint style="info" %}
**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.
{% endhint %}

***

## 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.

{% hint style="warning" %}
**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.
{% endhint %}

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

```yaml
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:

```yaml
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 <a href="#artifactory-registry" id="artifactory-registry"></a>

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 <a href="#amazon-s3-artifact" id="amazon-s3-artifact"></a>

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 <a href="#amazon-ecr" id="amazon-ecr"></a>

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

{% hint style="warning" %}
**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.
{% endhint %}

***

### Next steps <a href="#next-steps" id="next-steps"></a>

* Go to [Serverless infrastructure](/continuous-delivery/3.0/use-deployments/overview-2/serverless-infrastructure.md) to define your AWS deployment target.
* Go to [Serverless deployment](/continuous-delivery/3.0/use-deployments/overview-2/serverless-deployment.md) to configure execution steps and rollback.

{% @harness-feedback/feedback %}