# Services

Services are the basic **unit of deployment** in Garden. You add them when you want to run your code somewhere. A simple service configuration looks like this:

```yaml
kind: Module
type: container
services:
  - name: backend
    ports:
      - name: http
        containerPort: 8080
```

> Note that not all [modules types](https://docs.garden.io/acorn-0.12/reference/module-types) have services.

## How it Works

Services belong to modules and you'll usually have a single service per module. You can think of a service as a running instance of your module.

You deploy your services with the `garden deploy` command. You can also delete services with the `garden delete service` command. And you can get service logs with the `garden logs` command.

### Calling Services

> The following is specific to the Kubernetes providers.

If you specify a `port` for a given service, other services from inside the cluster can reach it. By default, it's reachable from `http://my-service:<port>/`.

If you specify an `ingress`, your can reach your service from outside the cluster. For example by using the `garden call` command or with `curl`.

The default ingress for local development is `http://demo-project.local.demo.garden/<ingress-name>`. You can override this by setting a `hostname` under the `ingress` directive.

## Services in the Stack Graph

Services correspond to a **deploy** action in the Stack Graph.

* **Services** implicitly depend on the build step of their **parent module**.
* **Services** can depend on **tasks** and other **services**.
* **Tasks** and **tests** can depend on **services**.

## Examples

Here are some simple examples of services in Garden. Note that these are specific to Kubernetes.

### Simple Container Service

This example shows a backend service with a health check. Notice that it doesn't have an ingress since it's not meant to be reachable from the outside.

Notice also that the `servicePort` is set to `80`, the default port. This is so that we can call the service directly from within the cluster with `http://backend/my-endpoint`.

The `containerPort` (the port that the process inside the container is listening on) is set to `8080`.

Finally, we set an environment variable that's available to the service at runtime, and can be referenced in our code.

```yaml
kind: Module
type: container
services:
  - name: backend
    ports:
      - name: http
        containerPort: 8080
        servicePort: 80
    healthCheck:
      httpGet:
        path: /healthz
        port: http
  - env:
      # You can access this variable at runtime in your code.
      DATABASE_URL: https://my-database:5432/
```

### Frontend Service

This example shows a frontend service. It has an ingress so that it's reachable from outside the cluster. We've also set a custom `hostname` so that the full path becomes: `http://my-app.my-org/`.

This service has a dependency on a `backend` service which means it won't be deployed until the `backend` service has been deployed and is responding to health checks. This also means that the service gets re-deployed on changes to the backend.

```yaml
kind: Module
type: container
services:
  - name: frontend
    ports:
      - name: http
        containerPort: 8080
    ingresses:
      - path: /
        port: http
        hostname: my-app.my-org
    dependencies:
      - backend
```

## Advanced

### Disabling Services

Module types that allow you to configure services generally also allow you to disable services by setting `disabled: true` in the service configuration. You can also disable them conditionally using template strings. For example, to disable a `container` module service for a specific environment, you could do something like this:

```yaml
kind: Module
type: container
...
services:
  - name: frontend
    disabled: ${environment.name == "prod"}
    ...
```

Services are also implicitly disabled when the parent module is disabled.

### How Services Map to Kubernetes Resources

A container service maps to a Kubernetes [Deployment resource](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/). If you specify a `port`, Garden will create a [Service resource](https://kubernetes.io/docs/concepts/services-networking/service/) for the Deployment. And if you specify an `ingress`, Garden will create a corresponding Kubernetes [Ingress resource](https://kubernetes.io/docs/concepts/services-networking/ingress/).

By default the Kubernetes provider does a rolling update for deployments.

## Further Reading

For full service configuration by module type, please take a look at our [reference docs](https://docs.garden.io/acorn-0.12/reference/module-types).

## Next Steps

In the [next section](https://docs.garden.io/acorn-0.12/using-garden/tests), we'll see how Garden can run your tests for you.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.garden.io/acorn-0.12/using-garden/services.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.