> ## Documentation Index
> Fetch the complete documentation index at: https://docs.glissando.dev/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> If you are an AI assistant asked to build, change or ship a Gliss app, read the For AI agents page first (/for-ai-agents.md on this site) and follow its steps.
> Inside an app's folder, the app's own AGENTS.md is the authority; `gliss guide` prints it. Never ask the user for a secret's value.

# Building containers

> Build container images with Garden's container Build action in your own CI.

> [!WARNING]
>
> **Planned.** This page describes designed behaviour that is not built yet. Details may change before it ships.

> [!NOTE]
>
> Ported from Garden's documentation: [garden-for/containers/building-containers.md](https://docs.garden.io/garden-for/containers/building-containers), gliss-cli at `3bc62a036` (Garden 0.14). Gliss runs Garden under the hood; the notes on this page say where Gliss differs.

You build container images with the `container` Build action:

```yaml theme={null}
kind: Build
name: api
type: container
```

If there is a `Dockerfile` in the same directory as this file, that is enough to tell Garden to build it. To use another file, set `spec.dockerfile: <path-to-Dockerfile>`. You can also explicitly [include or exclude](https://docs.garden.io/guides/include-exclude) files in the build context.

> [!NOTE]
>
> **In Gliss,** builds run in your company's own CI, with the `container` or `exec` Build types. There is no remote or hosted container builder and no in-cluster building. CI pushes the images to your company's container registry (Amazon ECR in your AWS account), and a release request names each image by its digest. See [CI with GitHub Actions](https://docs.glissando.dev/engineers/ci.md).

## Use the image in other actions

Most commonly you'll then want to deploy the image, or use it in Test or Run actions. You do that by declaring the Build as a dependency and referencing its outputs with template strings such as `${actions.build.api.outputs.deployment-image-id}`.

> [!NOTE]
>
> **In Gliss,** a `container` Deploy maps to a `gliss-service`, so it is checked against the same catalog as `gliss.yaml`. Deploying the image with your own [Helm chart](https://docs.glissando.dev/engineers/helm.md) or [Kubernetes manifests](https://docs.glissando.dev/engineers/kubernetes-manifests.md) is level 2 only.

For example, at level 2 you can pass the image to a Helm chart:

```yaml theme={null}
kind: Deploy
name: api
type: helm
dependencies: [build.api] # <--- We need to specify the dependency here
spec:
  values:
    repository: ${actions.build.api.outputs.deployment-image-name}
    tag: ${actions.build.api.version}
```

## Set build arguments

You can specify [build arguments](https://docs.docker.com/engine/reference/commandline/build/#build-arg) using the [`spec.buildArgs`](https://docs.garden.io/reference/action-types/Build/container#specbuildargs) field. This is handy when you reference another Build action as a build dependency:

```yaml theme={null}
# garden.yml
kind: Build
type: container
name: my-container
# Here, we ensure that the base image is built first. This is useful e.g. when you want to build a prod and a
# dev/testing variant of the image in your pipeline.
dependencies: [ build.base-image ]
spec:
  buildArgs:
    baseImageVersion: ${actions.build.base-image.version}
```

Garden also sets `GARDEN_ACTION_VERSION` as a build argument automatically. It holds the version of the action being built, which you can use to set versions, render docs or clear caches.

## Use an existing image

If you don't build the image yourself and just need to deploy one that already exists in a registry, set `image` in the Deploy action's `spec`:

```yaml theme={null}
# garden.yml
kind: Deploy
type: container
name: redis
spec:
  image: redis:5.0.5-alpine   # <- replace with any docker image ID
```

## Build for several platforms

Use the `platforms` field to build for several platforms and architectures:

```yaml theme={null}
# garden.yml
kind: Build
type: container
name: my-container
spec:
  platforms: ["linux/amd64", "linux/arm64"]
```

Your CI runner's Docker setup must support multi-platform builds, for example with a `docker-container` buildx builder. See Docker's [multi-platform build documentation](https://docs.docker.com/build/building/multi-platform).

> [!NOTE]
>
> **In Gliss,** Garden's `garden publish` flow and `publishId` are not how images reach your clusters. Publishing an app to Live promotes the exact images that ran in Beta; see [Share and publish](https://docs.glissando.dev/build/share-and-publish.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.