> For the complete documentation index, see [llms.txt](https://docs.garden.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.garden.io/bonsai-0.13/k8s-plugins/actions/deploy/container.md).

# Container

{% hint style="info" %}
The `container` action type is an abstraction that can be used with multiple plugins. [See here](/bonsai-0.13/other-plugins/container.md) for an in-depth guide on the action type itself. Continue reading for more information on the container deploy action type that can be used with the Kubernetes plugin.
{% endhint %}

The Kubernetes plugins can deploy `container` deploy actions.

Garden will take the simplified `container` deploy specification and convert it to Kubernetes manifests, i.e. Deployment, Service and (if applicable) Ingress resources.

For example:

```yaml
kind: Build
name: frontend
type: container
---
kind: Deploy
name: frontend
type: container
dependencies: [build.frontend] # <--- Need to specify the build as a dependency
spec:
  image: ${actions.build.frontend.outputs.deploymentImageId} # <--- The output from the Build action defined above
  ports:
    - name: http
      containerPort: 8080
  healthCheck:
    httpGet:
      path: /hello-frontend
      port: http
  ingresses:
    - path: /hello-frontend
      port: http
    - path: /call-backend
      port: http
...
```

To make sure Garden deploys the frontend with the right image version, we need to reference the output from the container build in the `spec.image` field.

We also configure a health check, a couple of ingress endpoints, and specify that this deploy depends on the `backend` deploy. There is a number of other options, which you can find in the `container` action [reference](/bonsai-0.13/reference/action-types/deploy/container.md).

If you need to use advanced (or otherwise very specific) features of the underlying platform, you may need to use more platform-specific action types (e.g. `kubernetes` or `helm`). The `container` action type is not intended to capture all those features.

## Environment variables

Container services can specify environment variables, using the `services[].env` field:

```yaml
kind: Deploy
name: frontend
type: container
spec:
  env:
    MY_ENV_VAR: foo
    MY_TEMPLATED_ENV_VAR: ${var.some-project-variable}
...
```

`env` is a simple mapping of "name: value". [Template strings](/bonsai-0.13/using-garden/variables-and-templating.md#template-string-overview) can also be used to interpolate values.

### Secrets

You can reference secrets in environment variables. For Kubernetes, this translates to `valueFrom.secretKeyRef` fields in the Pod specs, which direct Kubernetes to mount values from `Secret` resources that you have created in the application namespace, as environment variables in the Pod.

For example:

```yaml
kind: Deploy
name: frontend
type: container
spec:
  env:
    MY_SECRET_VAR:
      secretRef:
        name: my-secret
        key: some-key-in-secret
...
```

This will pull the `some-key-in-secret` key from the `my-secret` Secret resource in the application namespace, and make it available as an environment variable.

*Note that you must create the Secret manually for the Pod to be able to reference it.*

For Kubernetes, this is commonly done using `kubectl`. For example, to create a basic generic secret you could use:

```sh
kubectl --namespace <my-app-namespace> create secret generic --from-literal=some-key-in-secret=foo
```

Where `<my-app-namespace>` is your project namespace (which is either set with `namespace` in your provider config, or defaults to your project name). There are notably other, more secure ways to create secrets via `kubectl`. Please refer to the official [Kubernetes Secrets docs](https://kubernetes.io/docs/concepts/configuration/secret/#creating-a-secret-using-kubectl-create-secret) for details.

Also check out the [Kubernetes Secrets example project](https://github.com/garden-io/garden/blob/latest-release/examples/kubernetes-secrets/README.md) for a working example.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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/bonsai-0.13/k8s-plugins/actions/deploy/container.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.