> For the complete documentation index, see [llms.txt](https://docs.zerve.ai/self-managed/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zerve.ai/self-managed/install/installing-helm-chart.md).

# Installing Helm Chart

Before installing Zerve, please read through our [Prerequisites](/self-managed/install/prerequisites.md) page.

We don't publish our Helm charts and container images publicly, so you will be provided with access details to our private OCI registry separately. Once you have these, you can verify your access to the chart with a `helm pull`:

```
helm pull <registry>/zerve-chart --untar
```

Before running the `install` command you will need to provide some values, so that a basic application can start up.

## Minimal Values file

Below is the smallest set of values for a working install:

* external Postgres, Redis and Vault
* external OIDC provider
* one ingress host

Note: We support a wide range of topologies and configurations. You can find a version of this snippet, along with other examples for different configurations, in the `<chart-dir>/examples` folder of the installed chart.

```yaml
ingress:
  host: zerve.acme.com
  # omit this if you have a cluster-wide default Ingress Class configured
  className: <class name>

global:
  imagePullSecrets:
  - name: pull-creds

  workload:
    common:
      secrets:
        POSTGRES_PASSWORD:
          secretName: zerve-creds
          key: db_password
        INTERNAL_SERVICE_TOKEN:
          secretName: zerve-creds
          key: internal_token

      env:
        RESOURCE_PREFIX: "acme"
        REDIS_HOST: "redis.acme.internal"
        MSG_BROKER_REDIS_HOST: "redis.acme.internal"
        POSTGRES_HOST: "postgres.acme.internal"
        POSTGRES_USERNAME: "zerve"
        HASHICORP_VAULT_URL: "https://vault.acme.internal:8200"

user:
  workloads:
    common:
      env:
        OIDC_ISSUER: https://auth.acme.com/oidc
        OIDC_AUDIENCE: https://zerve.acme.com/api/user
        OIDC_CLIENT_ID: "<your-oidc-client-id>"

asset:
  workloads:
    common:
      secrets:
        HASHICORP_VAULT_TOKEN:
          secretName: zerve-creds
          key: vault_token

frontend:
  env:
    # Same IdP values as the user service above, from the browser's side.
    VITE_OIDC_AUTHORITY: https://auth.acme.com/oidc
    VITE_OIDC_CLIENT_ID: "<your-oidc-client-id>"
    VITE_OIDC_AUDIENCE: https://zerve.acme.com/api/user
```

Note: This snippet requires a few things already set up on the cluster:

* An Ingress controller
* `pull-creds` Secret with credentials to pull the images from our private registry. We'll provide you with these.
* `zerve-creds` Secret with the following keys:
  * `db_password` for Postgres password
  * `internal_token` for cross-service comms, can be any non-empty string
  * `vault_token` for Vault token

## Install the chart

With your minimal set of values prepared in `my-values.yaml`, run the following from the directory where you pulled the chart:

```
helm upgrade --install zerve . -f my-values.yaml
```

This should install a basic instance of Zerve on your cluster.

Note: To enable Notebook execution and Environment builds you will need to provide additional configuration through the [Execution Environment Manifest](/self-managed/configuration/execution-environment-manifest.md). This is **required** for a fully functional Zerve application.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.zerve.ai/self-managed/install/installing-helm-chart.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.