> 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/use-continuous-delivery/cd-building-blocks/services/services-overview.md).

# Services overview

A Harness service represents what you're deploying. Services represent your microservices and other workloads. Each service contains a **Service Definition** that defines your deployment artifacts, manifests or specifications, configuration files, and service-specific variables.

Harness services are deployed to Harness environments. Select **Environments** to see the environments in this project.

Select **Services** to see the service list for your project. From this dashboard, you can create new services and monitor your existing ones.

### Video: Services <a href="#video-services" id="video-services"></a>

{% embed url="<https://youtu.be/MVuzJjAzsQs>" %}

#### Video: Services and environments at the account and org level <a href="#video-services-and-environments-at-the-account-and-org-level" id="video-services-and-environments-at-the-account-and-org-level"></a>

{% embed url="<https://youtu.be/qU00SaLH78Q>" %}

### Creating services <a href="#creating-services" id="creating-services"></a>

You can create services from:

* An account
* An organization
* Within a pipeline
* Outside a pipeline

When you create a service in a pipeline, it's automatically added to **Services**. You can add the same service to as many pipelines as you need.

For more information, go to [create services](/continuous-delivery/use-continuous-delivery/cd-building-blocks/services/create-services.md).

#### Creating services at an account or organization level <a href="#creating-services-at-an-account-or-organization-level" id="creating-services-at-an-account-or-organization-level"></a>

You can create a service at an account or organization level from the Harness UI using APIs or Terraform.

{% tabs %}
{% tab title="Pipeline Studio" %}
To create a service at an account or organization level, go to **Organization Resources** **>Services**.

Creating an account level service enables you to manage the service globally across the organizations and projects within the account.

An account level service can only reference connectors for the manifests and artifacts within the account. These services are global and cannot have dependencies at a lower hierarchy level.

Shared services can also be created and managed at account or organization levels.

![](/files/WWpnBEnmVMWHemIIX24s)

{% hint style="info" %}
When using an account level deployment stage template, you can reference an account level service only. Similarly, for organization level stage templates, you can reference organization level services only.

However, when using a deployment stage in a pipeline that has service configured as a runtime input, you can pick services from project, organization, or account levels to pass them as runtime inputs based on your RBAC.

Go to [add a stage template](/harness-ai/use-harness-platform/templates/add-a-stage-template.md) for more information.
{% endhint %}

Expand the section below to see a sample account level service YAML.

<details>

<summary>Account level service YAML</summary>

```yaml
service:
  name: nginx
  identifier: nginx
  tags: {}
  serviceDefinition:
    spec:
      manifests:
        - manifest:
            identifier: nginx-base
            type: K8sManifest
            spec:
              store:
                type: Github
                spec:
                  connectorRef: account.Harness_K8sManifest
                  gitFetchType: Branch
                  paths:
                    - cdng/
                  repoName: <+input>
                  branch: main
              skipResourceVersioning: false
      artifacts:
        primary:
          primaryArtifactRef: <+input>
          sources:
            - spec:
                connectorRef: account.Harness_DockerHub
                imagePath: library/nginx
                tag: <+input>
                digest: <+input>
              identifier: harness dockerhub
              type: DockerRegistry
    type: Kubernetes
```

</details>

Expand the section below to see a sample organization level service YAML.

<details>

<summary>Organization level service YAML</summary>

```yaml
service:
  name: redis
  identifier: redis
  tags: {}
  serviceDefinition:
    spec:
      manifests:
        - manifest:
            identifier: redis
            type: HelmChart
            spec:
              store:
                type: Http
                spec:
                  connectorRef: org.bitnami
              chartName: redis
              chartVersion: ""
              subChartName: ""
              helmVersion: V3
              skipResourceVersioning: false
              enableDeclarativeRollback: false
        - manifest:
            identifier: Redis Values
            type: Values
            spec:
              store:
                type: Github
                spec:
                  connectorRef: account.Rohan_Github
                  gitFetchType: Branch
                  paths:
                    - redis/values.yaml
                  repoName: Product-Management
                  branch: main
      variables:
        - name: namespace
          type: String
          description: "namespace for the redis service"
          value: redis
    type: Kubernetes
  description: sample redis service
```

</details>
{% endtab %}

{% tab title="API" %}
For information about creating a service API, go to [create a service](https://apidocs.harness.io/tag/Services#operation/createServiceV2).

The `orgIdentifier` and `projectIdentifier` field definitions are optional, and depend on where you want to create the service. For example, if you create a service at an account level, you will not need org or project identifiers in the post API call payload.
{% endtab %}

{% tab title="Terraform" %}
For information about creating a Harness platform service, go to [harness\_platform\_service (Resource)](https://registry.terraform.io/providers/harness/harness/latest/docs/resources/platform_service).

The `org_id` and `project_id` field definitions are optional, and depend on where you want to create the service. For example, if you create a service at an account level, you will not need org or project identifiers.

Expand the section below to see a sample platform service in Terraform.

<details>

<summary>Harness platform service</summary>

```hcl
resource "harness_platform_service" "example" {
  identifier  = "identifier"
  name        = "name"
  description = "test"
  org_id      = "org_id"
  project_id  = "project_id"

  ## SERVICE V2 UPDATE
  ## We now take in a YAML that can define the service definition for a given Service
  ## It isn't mandatory for Service creation
  ## It is mandatory for Service use in a pipeline

  yaml = <<-EOT
                service:
                  name: name
                  identifier: identifier
                  serviceDefinition:
                    spec:
                      manifests:
                        - manifest:
                            identifier: manifest1
                            type: K8sManifest
                            spec:
                              store:
                                type: Github
                                spec:
                                  connectorRef: <+input>
                                  gitFetchType: Branch
                                  paths:
                                    - files1
                                  repoName: <+input>
                                  branch: master
                              skipResourceVersioning: false
                      configFiles:
                        - configFile:
                            identifier: configFile1
                            spec:
                              store:
                                type: Harness
                                spec:
                                  files:
                                    - <+org.description>
                      variables:
                        - name: var1
                          type: String
                          value: val1
                        - name: var2
                          type: String
                          value: val2
                    type: Kubernetes
                  gitOpsEnabled: false
              EOT
}
```

</details>
{% endtab %}
{% endtabs %}

#### Creating services outside a pipeline <a href="#creating-services-outside-a-pipeline" id="creating-services-outside-a-pipeline"></a>

To create a service from outside of a pipeline, you use **Services** in the navigation pane.

![](/files/fmli54iMR9vYThacO7iy)

#### Creating services inside a pipeline <a href="#creating-services-inside-a-pipeline" id="creating-services-inside-a-pipeline"></a>

To create a service from inside of a pipeline, select the **Services** tab of a new CD stage, then select **New Service**.

![](/files/BtUZWRtMXHOlsP97Ztvt)

Once the service and its service definition are saved, you can select it in any pipeline.

When you select the service in a pipeline, you can select **Edit Service** to edit its **Service Definition**.

When you create the new service you define its **Service Definition**. For example, a Kubernetes **Service Definition** with a Kubernetes manifest and Docker artifact.

### Clone Services <a href="#clone-services" id="clone-services"></a>

You can clone services across scopes i.e from one project to another, project to organization, account to project etc.

Select **More Options** (⋮), then select **Clone**.

![](/files/bx5gO5zjhrOPVD0XWWoI)

Once you click on **Clone**, you will see **Clone Service** settings:

You can change the **Name**, add tags and description for this clone service.

You can change the **Organization** and **Project** where you want to clone the service.

You can choose between **Inline** and **Remote** to set up your service. Choose **Inline** when you want your service to be stored in Harness. Choose **Remote** when storing your service in a Third-party Git repository or Harness Code Repository.

To clone a remote service to an inline service, you have to specify the source branch where the remote service is stored.

![](/files/XiymaRBQWYJd8qSAHqmU)

To clone an inline service or remote service to a remote service, you must specify the target repository, Harness Code Repository to store the service in the Harness repository or Third-party Git provider to store the service in a third party Git provider, define the Git Connector if Third-party Git provider. Specify the Repository name, the YAML path, and the commit message.

![](/files/D2A9poOvc42pKR6SBEXV)

{% hint style="info" %}
**NOTE**

When you clone a service from a different organization or project, the connector referenced in the service doesn't get cloned and must be explicitly created.
{% endhint %}

### Runtime inputs and expressions in services <a href="#runtime-inputs-and-expressions-in-services" id="runtime-inputs-and-expressions-in-services"></a>

If you use runtime inputs in your services, users will need to provide values for these when they run pipelines using these services.

If you use expressions in your services, Harness must be able to resolve these expressions when users run pipelines using these services.

Select **Runtime input** for the service.

![](/files/77xGOcuLC9QtnXOp0uLP)

When you run the pipeline, you can select the service for runtime inputs.

![](/files/36qVZI568vePkuy1NlCE)

For more information on runtime inputs and expressions, go to [Fixed Values, Runtime Inputs, and Expressions](/harness-ai/use-harness-platform/variables-and-expressions/runtime-inputs.md).

### Services RBAC <a href="#services-rbac" id="services-rbac"></a>

Go to [RBAC in Harness](/harness-ai/use-harness-platform/platform-access-control.md) for examples of RBAC use cases for services.

#### Access permission is needed to deploy to a service <a href="#access-permission-is-needed-to-deploy-to-a-service" id="access-permission-is-needed-to-deploy-to-a-service"></a>

One of the most important advantages of services is the ability to define roles that determines who can deploy them.

In order for a role to allow deployments using services, the role must have the access permission enabled for services.

![](/files/AYLUJZyFC9OkPanxGbvF)

The **View**, **Create**, **Edit**, **Delete**, and **Manage** permissions enable you to deploy a service.

If a role does not have the **Access** permission for **Services**, a user or user group assigned that role cannot deploy any service.

#### Restrict access to specific services for a user or user group <a href="#restrict-access-to-specific-services-for-a-user-or-user-group" id="restrict-access-to-specific-services-for-a-user-or-user-group"></a>

You can restrict a user or user group to using specific services only.

If you want to restrict a user or user group to deploy using a specific service only, do the following:

1. Create a resource group and select the service.
2. Create a role and give the user or user group permissions. The **Access** permission is needed for deployments.
3. Assign the role and resource group to the user or user group.

![](/files/nPhUFHIpxAP7pMBsFG9l)

### Metadata sync with bidirectional sync <a href="#metadata-sync-with-bidirectional-sync" id="metadata-sync-with-bidirectional-sync"></a>

When you store a service remotely in Git with [bidirectional sync](/harness-ai/use-harness-platform/git-experience/gitexp-bidir-sync-setup.md) enabled, Harness automatically syncs entity metadata — **name**, **description**, and **tags** — back to Harness when those fields are updated on the Git side for the default branch.

Previously, modifying service metadata directly in the Git repository did not propagate those changes to Harness, requiring a separate update from the Harness UI. With metadata sync, any change committed to the default branch in Git is reflected in Harness automatically. This sync applies only to the default branch; metadata changes on other branches are not synced.

{% hint style="info" %}
**NOTE**

This feature is behind the feature flag `CDS_GITX_WEBHOOK_SYNC_ENTITY_METADATA`. Contact [Harness Support](mailto:support@harness.io) to enable it.
{% endhint %}

### Deleting a Service in Harness <a href="#deleting-a-service-in-harness" id="deleting-a-service-in-harness"></a>

For information on deleting services in Harness, go to **Deleting a Service in Harness** in [Service-based licensing and usage for CD](/continuous-delivery/troubleshooting-and-resources/resources/service-licensing-for-cd.md).