tyk-stack-chart.md

---
title: Tyk Stack Chart
description: Install and configure Tyk Stack Chart
tags: ["Tyk Stack chart", "Tyk Stack Chart", "helm charts", "helm", "charts", "kubernetes", "k8s"]
aliases:
  - /deployment-and-operations/tyk-self-managed/deployment-lifecycle/installations/kubernetes/tyk-helm-tyk-stack
  - /tyk-self-managed/tyk-helm-chart-single-dc
---

The `tyk-stack` chart provides the default deployment of Tyk Self Managed on a Kubernetes cluster. It will deploy all required Tyk components with the settings provided in the values.yaml file.

## What components are deployed with Tyk Stack Chart?

It includes:
- Tyk Gateway, an Open Source Enterprise API Gateway (supporting REST, GraphQL, TCP and gRPC protocols).
- Tyk Pump, an analytics purger that moves the data generated by your Tyk nodes to any back-end. Furthermore, it has all the required modifications to easily connect to Tyk Cloud or Multi Data Center (MDCB) control plane.
- Tyk Dashboard, a license based component that provides a graphical management interface and analytics platform for Tyk.
- Tyk Developer Portal, a full-fledged CMS-like system for API providers to publish, monetise and drive the adoption of APIs.

By default, this chart installs the following components as sub-charts on a [Kubernetes](https://kubernetes.io/) cluster using the [Helm](https://helm.sh/) package manager.

| Component                       | Enabled by Default | Flag                        |
|---------------------------------|--------------------|-----------------------------|
| Tyk Gateway                     | true               | n/a                         |
| Tyk Dashboard                   | true               | n/a                         |
| Tyk MDCB                        | true               | n/a                         |
| Tyk Pump                        | false              | global.components.pump      |
| Tyk Enterprise Developer Portal | false              | global.components.devPortal | 
| Tyk Operator                    | false              | global.components.operator  |

To enable or disable each component, change the corresponding enabled flag.

Also, you can set the version of each component through `image.tag`. You can find the list of version tags available from [Docker hub](https://hub.docker.com/u/tykio).

For quick start guide, please see [Quick Start with Helm Chart and PostgreSQL]({{<ref "/deployment-and-operations/tyk-self-managed/deployment-lifecycle/installations/kubernetes/tyk-helm-tyk-stack-postgresql">}}) or [Quick Start with Helm Chart and MongoDB]({{<ref "/deployment-and-operations/tyk-self-managed/deployment-lifecycle/installations/kubernetes/tyk-helm-tyk-stack-mongodb">}}).

## Prerequisites

* [Kubernetes 1.19+](https://kubernetes.io/docs/setup/)
* [Helm 3+](https://helm.sh/docs/intro/install/)
* [Redis](https://tyk.io/docs/tyk-oss/ce-helm-chart/#recommended-via-bitnami-chart) should already be installed or accessible by the gateway and dashboard.
* [MongoDB](https://www.mongodb.com) or [PostgreSQL](https://www.postgresql.org) should already be installed or accessible by dashboard. Please consult the list of [supported versions]({{< ref "tyk-dashboard/database-options" >}}) that are compatible with Tyk.

{{< note success >}}
**Note**

If you want to enable Tyk Developer Portal, please use PostgreSQL. MongoDB is not supported in Developer Portal.
{{< /note >}}

## Tyk Stack Installations
### Installing The Chart

To install the chart from Helm repository in namespace `tyk` with the release name `tyk-stack`:
```bash
helm repo add tyk-helm https://helm.tyk.io/public/helm/charts/
helm repo update
helm show values tyk-helm/tyk-stack > values.yaml
```

For further documentation relating to *helm* command usage, please refer to the [helm docs](https://helm.sh/docs/helm/).

At a minimum, modify values.yaml for the following settings:
1. [Set Redis connection details](#set-redis-connection-details-required)
2. [Set Mongo or PostgresSQL connection details](#set-mongo-or-postgressql-connection-details-required)
3. [Dashboard License](#tyk-dashboard-license-required)

If you would like to use Developer Portal, an additional license is required:

4. [Developer Portal License](#tyk-developer-portal-license-required)

Then just run:
```bash
helm install tyk-stack tyk-helm/tyk-stack -n tyk --create-namespace -f values.yaml
```

### Uninstalling The Chart

```bash
helm uninstall tyk-stack -n tyk
```
This removes all the Kubernetes components associated with the chart and deletes the release.

### Upgrading Chart

```bash
helm upgrade tyk-stack tyk-helm/tyk-stack -n tyk -f values.yaml
```

## Configuration

To list all configurable options with detailed comments:

```bash
helm show values tyk-helm/tyk-stack > values.yaml
```

You can update any value in your local `values.yaml` file and use `-f [filename]` flag to override default values during installation. 
Alternatively, you can use `--set` flag to set it in Tyk installation. See [Using Helm](https://helm.sh/docs/intro/using_helm/) for examples.

To configure Tyk components, users can utilize both config files and [environment variables](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/). Notably, environment variables take precedence over config files. To maintain simplicity and consistency, the Tyk Helm Charts deploy components with an empty config file while setting container environment variables based on user-defined [values](https://helm.sh/docs/chart_best_practices/values/). This approach ensures seamless integration with Kubernetes practices, allowing for efficient management of configurations. For a comprehensive overview of available configurations, please refer to the [configuration documentation]({{<ref "tyk-environment-variables">}}). 

### Setting Environment Variables
Should any environment variables not be set by the Helm Chart, users can easily add them under the `extraEnvs` section within the charts for further customization. Values set under `extraEnvs` would take precedence over all configurations.

Example of setting extra environment variable to gateway:
```yaml
tyk-gateway:
  gateway:
    extraEnvs:
    - name: TYK_GW_LOGLEVEL
      value: debug
```

An example is listed below for setting extra [environment variable using ConfigMap data](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#define-container-environment-variables-using-configmap-data), using gateway:
```yaml
tyk-gateway:
  gateway:
    extraEnvs:
    - name: CONFIG_USERNAME
      valueFrom:
        configMapKeyRef: 
          name: backend-user
          key: backend-username
```

An example is listed below for setting extra [environment variable using secret data](https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/#define-container-environment-variables-using-secret-data), using gateway:
```yaml
tyk-gateway:
  gateway:
    extraEnvs:
    - name: SECRET_USERNAME
      valueFrom:
        secretKeyRef: 
          name: backend-user
          key: backend-username
```

In the above example, an extra environment variable `SECRET_USERNAME` will be added to the Gateway container, with a value of `backend-username` associated with the secret `backend-user`. It is useful if you want to access secret data from [Tyk Gateway configuration file (tyk.conf) or API definitions]({{<ref "tyk-configuration-reference/kv-store#how-to-access-the-externally-stored-data">}}).

### Set Redis Connection Details (Required)

Tyk uses Redis for distributed rate-limiting and token storage. You may use the Bitnami chart to install or Tyk's `simple-redis` chart for POC purpose.

Set the following values after installing Redis:

| Name | Description | 
|------|-------------|
| `global.redis.addrs` | Redis addresses |
| `global.redis.pass` | Redis password in plain text |
| `global.redis.passSecret.name` | If global.redis.pass is not provided, you can store it in a secret and provide the secret name here |
| `global.redis.passSecret.keyName` | key name to retrieve redis password from the secret |

***Recommended: via *Bitnami* chart***

For Redis you can use these rather excellent charts provided by [Bitnami](https://github.com/bitnami/charts/tree/main/bitnami/redis).
Copy the following commands to add it:

```bash
helm upgrade tyk-redis oci://registry-1.docker.io/bitnamicharts/redis -n tyk --create-namespace --install --version 19.0.2
```

{{< note success >}}
**Note**

Please make sure you are installing Redis versions that are supported by Tyk. Please refer to Tyk docs to get list of [supported versions]({{< ref "planning-for-production/redis" >}}).
{{< /note >}}

Follow the notes from the installation output to get connection details and password.

```
  Redis(TM) can be accessed on the following DNS names from within your cluster:

    tyk-redis-master.tyk.svc.cluster.local for read/write operations (port 6379)
    tyk-redis-replicas.tyk.svc.cluster.local for read-only operations (port 6379)

  export REDIS_PASSWORD=$(kubectl get secret --namespace tyk tyk-redis -o jsonpath="{.data.redis-password}" | base64 --decode)
```

The Redis address as set by Bitnami is `tyk-redis-master.tyk.svc.cluster.local:6379`

You can reference the password secret generated by Bitnami chart by  `--set global.redis.passSecret.name=tyk-redis` and `--set global.redis.passSecret.keyName=redis-password`, or just set `global.redis.pass=$REDIS_PASSWORD`

***Evaluation only: via *simple-redis* chart***

Another option for Redis, to get started quickly, is to use our [simple-redis](https://artifacthub.io/packages/helm/tyk-helm/simple-redis) chart.

{{< warning  success >}}
**Warning**

Please note that these provided charts must never be used in production or for anything
but a quick start evaluation only. Use [Bitnami Redis](https://github.com/bitnami/charts/tree/main/bitnami/redis) or [Official Redis installation guides](https://redis.io/docs/install/) in any other case.
We provide this chart, so you can quickly deploy *Tyk gateway*, but it is not meant for long term storage of data.

{{< /warning >}}

```bash
helm install redis tyk-helm/simple-redis -n tyk
```

The Tyk Helm Chart can connect to `simple-redis` in the same namespace by default. You do not need to set Redis address and password in `values.yaml`.

### Set Mongo or PostgresSQL Connection Details (Required)
If you have already installed MongoDB or PostgreSQL, you can set the connection details in the `global.mongo` and `global.postgres` sections of the values.yaml file respectively.

If not, you can use these rather excellent charts provided by Bitnami to install MongoDB or PostgreSQL:

**Mongo Installation**

```bash
helm install tyk-mongo bitnami/mongodb --set "replicaSet.enabled=true" -n tyk --version 15.1.2
```

{{< note success >}}
**Note**

Bitnami MongoDB image is not supported on darwin/arm64 architecture.
{{< /note >}}

Then follow notes from the installation output to get connection details and update them in `values.yaml` file.

{{< note success >}}
**Note**

Please make sure you are installing MongoDB versions that are supported by Tyk. Please refer to Tyk docs to get list of [supported versions]({{< ref "tyk-dashboard/database-options" >}}).
{{< /note >}}

{{< note success >}}
**Note**

Important Note regarding MongoDB:

This helm chart enables the `PodDisruptionBudget` for MongoDB with an arbiter replica-count of 1. If you intend to perform system maintenance on the node where the MongoDB pod is running and this maintenance requires the node to be drained, then this action will be prevented due to the the replica count being 1.

Increase the replica count in the helm chart deployment to a minimum of 2 to remedy this issue.
{{< /note >}}

Configure `global.mongo.mongoURL` and `global.storageType` as below. You should replace password in the connection string with the MONGODB_ROOT_PASSWORD you obtain from the installation output notes.

```yaml
global:
  # Set mongo connection details if you want to configure mongo pump.
  mongo:
    # The mongoURL value will allow you to set your MongoDB address.
    # Default value: mongodb://mongo.{{ .Release.Namespace }}.svc:27017/tyk_analytics
    # mongoURL: mongodb://mongo.tyk.svc:27017/tyk_analytics

    # If your MongoDB has a password you can add the username and password to the url
    mongoURL: mongodb://root:pass@tyk-mongo-mongodb.tyk.svc:27017/tyk_analytics?authSource=admin

    # mongo-go driver is supported for Tyk 5.0.2+.
    # We recommend using the mongo-go driver if you are using MongoDB 4.4.x+.
    # For MongoDB versions prior to 4.4, please use the mgo driver.
    # Since Tyk 5.3 the default driver is mongo-go.
    driver: mongo-go

    # Connection URL can also be set using a secret. Provide the name of the secret and key below.
    # connectionURLSecret:
    #   name: ""
    #   keyName: ""

    # Enables SSL for MongoDB connection. MongoDB instance will have to support that.
    # Default value: false
    useSSL: false

  # Choose the storageType for Tyk. [ "mongo", "postgres" ]
  storageType: &globalStorageType mongo
```

**PostgresSQL Installation**
```bash
helm install tyk-postgres bitnami/postgresql --set "auth.database=tyk_analytics" -n tyk --version 12.12.10
```

Follow the notes from the installation output to get connection details.

{{< note success >}}
**Note**

Please make sure you are installing PostgreSQL versions that are supported by Tyk. Please refer to Tyk docs to get list of [supported versions]({{< ref "tyk-dashboard/database-options" >}}).
{{< /note >}}

```yaml
global:
  # PostgreSQL connection string parameters.
  postgres:
    # host corresponds to the host name of postgreSQL
    host: tyk-postgres-postgresql.tyk.svc
    # port corresponds to the port of postgreSQL
    port: 5432
    # user corresponds to the user of postgreSQL
    user: postgres
    # password corresponds to the password of the given postgres user in selected database
    password:
    # database corresponds to the database to be used in postgreSQL
    database: tyk_analytics
    # sslmode corresponds to if postgreSQL runs in sslmode (https)
    sslmode: disable
    # Connection string can also be set using a secret. Provide the name of the secret and key below.
    # connectionStringSecret:
    #   name: ""
    #   keyName: ""
```

### Protect Confidential Fields with Kubernetes Secrets

In the `values.yaml` file, some fields are considered confidential, such as `APISecret`, connection strings, etc.
Declaring values for such fields as plain text might not be desired. Instead, for certain fields,
Kubernetes secrets can be referenced and the chart will [define container environment variables using secret data](https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/#define-container-environment-variables-using-secret-data).

This section describes how to use Kubernetes secrets to declare confidential fields.

***Tyk Dashboard and Developer Portal Admin***

If Tyk Dashboard bootstrapping is enabled, the admin user will be created according to the `global.adminUser` field.

All admin credentials can also be set through Kubernetes secret.

{{< note success >}}
**Note**

Once `global.adminUser.useSecretName` is declared, it takes precedence over `global.adminUser.firstName`, 
`global.adminUser.lastName`, `global.adminUser.email` and `global.adminUser.password`.

If `global.adminUser.useSecretName` is in use, please add all keys mentioned below to the secret.
{{< /note >}}

***Tyk Dashboard Admin First Name***

It can be configured via `global.adminUser.firstName` as a plain text or Kubernetes secret which includes `adminUserFirstName` key in it. Then, this secret must be referenced via `global.adminUser.useSecretName`.


***Tyk Dashboard Admin Last Name***

It can be configured via `global.adminUser.lastName` as a plain text or Kubernetes secret which includes `adminUserLastName` key in it. Then, this secret must be referenced via `global.adminUser.useSecretName`.

***Tyk Dashboard and Developer Portal Admin Email***

It can be configured via `global.adminUser.email` as a plain text or Kubernetes secret which includes `adminUserEmail` key in it. Then, this secret must be referenced via `global.adminUser.useSecretName`.


***Tyk Dashboard and Developer Portal Admin Password***

It can be configured via `global.adminUser.password` as a plain text or Kubernetes secret which includes `adminUserPassword` key in it. Then, this secret must be referenced via `global.adminUser.useSecretName`.

***APISecret***

The `global.secrets.APISecret` field configures a [header value]({{< ref "tyk-oss-gateway/configuration#secret" >}}) used in every interaction with Tyk Gateway API.

It can be configured via `global.secrets.APISecret` as a plain text or Kubernetes secret which includes `APISecret` key in it. Then, this secret must be referenced via `global.secrets.useSecretName`.

```yaml
global:
    secrets:
        APISecret: CHANGEME
        useSecretName: "mysecret" # where mysecret includes `APISecret` key with the desired value.
```

***AdminSecret***

The `global.secrets.AdminSecret` field sets a [secret]({{< ref "tyk-dashboard/configuration#admin_secret" >}}) for Admin API.

It can be configured via `global.secrets.AdminSecret` as a plain text or Kubernetes secret which includes `AdminSecret` key in it. Then, this secret must be referenced via `global.secrets.useSecretName`.

```yaml
global:
    secrets:
        useSecretName: "mysecret" # where mysecret includes `AdminSecret` key with the desired value.
```

{{< note success >}}
**Note**

Once `global.secrets.useSecretName` is declared, it takes precedence over `global.secrets.APISecret` and `global.secrets.AdminSecret`.
{{< /note >}}

***Dashboard License***

In order to refer Tyk Dashboard license using a Kubernetes secret, please use `global.secrets.useSecretName`, where the secret should contain a key called `DashLicense`.

***Tyk Developer Portal License***

In order to refer Tyk Developer Portal license using a Kubernetes secret, please use 
`tyk-dev-portal.useSecretName`, where the secret should contain a key called `DevPortalLicense`.

***Tyk Developer Portal Admin Password***

In order to refer Tyk Developer Portal's admin password using a Kubernetes secret, 
please use `global.adminUser.useSecretName`, where the secret should contain a key called `adminUserPassword`.

***Tyk Developer Portal Storage Connection String***

In order to refer Tyk Developer Portal connection string to the selected database using a Kubernetes secret, please use `tyk-dev-portal.useSecretName`, where the secret should contain a key called 
`DevPortalStorageConnectionString`.

{{< note success >}}
**Note**

If `tyk-dev-portal.useSecretName` is in use, please add all keys mentioned to the secret. 
{{< /note >}}

***Tyk Developer Portal AWS S3 Access Key ID***

In order to refer to the Tyk Developer Portal AWS S3 Access Key ID using a Kubernetes secret, please use `tyk-dev-portal.useSecretName`, where the secret should contain a key called `DevPortalAwsAccessKeyId`.

{{< note success >}}
**Note**

If `tyk-dev-portal.useSecretName` is in use, please add all keys mentioned to the secret.
{{< /note >}}

***Tyk Developer Portal AWS S3 Secret Access Key***

In order to refer Tyk Developer Portal connection string to the selected database through Kubernetes secret,
please use `tyk-dev-portal.useSecretName`, where the secret should contain a key called 
`DevPortalAwsSecretAccessKey`.

{{< note success >}}
**Note**

If `tyk-dev-portal.useSecretName` is in use, please add all keys mentioned to the secret.
{{< /note >}}

***Redis Password***

Redis password can also be provided via a secret. Store the Redis password in a Kubernetes secret and refer to this secret as follows:

```yaml
global:  
  redis:
     passSecret:
       name: "yourSecret"
       keyName: "redisPassKey"
```

***MongoDB or PostgreSQL connection strings***

Storage connection strings can also be provided via a secret. Store the connection string in Kubernetes secret and refer to this secret via `global.{mongo,postgres}.connectionURLSecret.name` and `global.{mongo,postgres}.connectionURLSecret.keyName` field, as follows:

- MongoDB:
```yaml
global:  
  mongo:
    connectionURLSecret:
       name: "yourSecret"
       keyName: "mongoConnectionURLkey"
```

- PostgreSQL:
```yaml
global:
  postgres:
    connectionStringSecret:
       name: "yourSecret"
       keyName: "postgreConnectionURLkey"
```

### Gateway Configurations

This section explains how to configure the `tyk-gateway` section for updating the Gateway version, enabling TLS, enabling autoscaling etc.

#### Update Tyk Gateway Version
Set version of gateway at `tyk-gateway.gateway.image.tag`. You can find the list of version tags available from [Docker hub](https://hub.docker.com/r/tykio/tyk-gateway/tags). Please check [Tyk Release notes]({{<ref "/product-stack/tyk-gateway/release-notes/overview">}}) carefully while upgrading or downgrading.

#### Enabling TLS

*Enable TLS*

We have provided an easy way to enable TLS via the `global.tls.gateway` flag. Setting this value to true will
automatically enable TLS using the certificate provided under tyk-gateway/certs/.

*Configure TLS secret*

If you want to use your own key/cert pair, please follow the following steps:
1. Create a TLS secret using your cert and key pair.
2. Set `global.tls.gateway` to true.
3. Set `tyk-gateway.gateway.tls.useDefaultTykCertificate` to false.
4. Set `tyk-gateway.gateway.tls.secretName` to the name of the newly created secret.

*Add Custom Certificates*

To add your custom Certificate Authority(CA) to your containers, you can mount your CA certificate directly into /etc/ssl/certs folder.

```yaml
   extraVolumes: 
     - name: self-signed-ca
       secret:
         secretName: self-signed-ca-secret
   extraVolumeMounts: 
     - name: self-signed-ca
       mountPath: "/etc/ssl/certs/myCA.pem"
       subPath: myCA.pem
```

#### Enabling gateway autoscaling
You can enable autoscaling of the gateway by `--set tyk-gateway.gateway.autoscaling.enabled=true`. By default, it will enable the `Horizontal Pod Autoscaler` resource with target average CPU utilisation at 60%, scaling between 1 and 3 instances. To customise those values you can modify the tyk-gateway section of the `values.yaml` file as shown below:

```yaml
tyk-gateway:
  gateway:
    autoscaling:
      enabled: true
      minReplicas: 3
      maxReplicas: 30
```

Built-in rules include `tyk-gateway.gateway.autoscaling.averageCpuUtilization` for CPU utilization (set by default at 60%) and `tyk-gateway.gateway.autoscaling.averageMemoryUtilization` for memory (disabled by default). In addition to that you can define rules for custom metrics using `tyk-gateway.gateway.autoscaling.autoscalingTemplate` list:

```yaml
tyk-gateway:
  gateway:
    autoscaling:
      autoscalingTemplate:
        - type: Pods
          pods:
            metric:
              name: nginx_ingress_controller_nginx_process_requests_total
            target:
              type: AverageValue
              averageValue: 10000m
```

#### Accessing Gateway

*Service port*

Default service port of gateway is 8080. You can change this at `global.servicePorts.gateway`.

*Ingress*

An Ingress resource is created if `tyk-gateway.gateway.ingress.enabled` is set to true.

```yaml
    ingress:
      # if enabled, creates an ingress resource for the gateway
      enabled: true

      # specify ingress controller class name
      className: ""

      # annotations for ingress
      annotations: {}

      # ingress rules
      hosts:
        - host: tyk-gw.local
          paths:
            - path: /
              pathType: ImplementationSpecific

      # tls configuration for ingress
      #  - secretName: chart-example-tls
      #    hosts:
      #      - chart-example.local
      tls: []
```

*Control Port*

Set `tyk-gateway.gateway.control.enabled` to true will allow you to run the [Gateway API]({{<ref "/tyk-gateway-api">}}) on a separate port and protect it behind a firewall if needed.

#### Sharding

Configure the gateways to load APIs with specific tags only by enabling `tyk-gateway.gateway.sharding.enabled`, and set `tags` to comma separated lists of matching tags.

```yaml
    # Sharding gateway allows you to selectively load APIs to specific gateways.
    # If enabled make sure you have at least one gateway that is not sharded.
    # Also be sure to match API segmentation tags with the tags selected below.
    sharding:
      enabled: true
      tags: "edge,dc1,product"
```

#### Deploy additional gateway groups

The `tyk-stack` chart manages one Gateway deployment in the same namespace as Tyk Dashboard. You can flexibly deploy additional gateways using `tyk-gateway` component chart. With gateway sharding, it is useful for:
- Deploying Gateways in different networks,
- Deploying Gateways with different resources and autoscaling parameters,
- Allow different teams to manage their own Gateway instances in their own namespace.

Here is an example configuration for `tyk-gateway` `values.yaml`.
```yaml
global:
  redis:
    addrs:
      - tyk-redis-master.tyk-stack.svc:6379       # New Gateway groups should connect to the same Redis
    pass: "xxxxxxx"

gateway:
  # If this option is set to true, it will enable polling the Tyk Dashboard service for API definitions
  useDashboardAppConfig:
    enabled: true
      # Set it to the URL to your Dashboard instance (or a load balanced instance)
      # The URL needs to be formatted as: http://dashboard_host:port
      # It is used to set TYK_GW_DBAPPCONFOPTIONS_CONNECTIONSTRING
      dashboardConnectionString: "http://dashboard-svc-tyk-tyk-dashboard.tyk-stack.svc:3000"

      # This option is required if Policy source is set to Tyk Dashboard (`service`).
      # Set this to the URL of your Tyk Dashboard installation.
      # The URL needs to be formatted as: http://dashboard_host:port.
      # It is used to set TYK_GW_POLICIES_POLICYCONNECTIONSTRING
      policyConnectionString: "http://dashboard-svc-tyk-tyk-dashboard.tyk-stack.svc:3000"

  ...

  # Sharding gateway allows you to selectively load APIs to specific gateways.
  # If enabled make sure you have at least one gateway that is not sharded.
  # Also be sure to match API segmentation tags with the tags selected below.
  sharding:
    enabled: true
    tags: "gw-dmz"

  ...

  # analyticsEnabled property is used to enable/disable analytics.
  # If set to empty or nil, analytics will be enabled/disabled based on `global.components.pump`.
  analyticsEnabled: "true"

  # used to decide whether to send the results back directly to Tyk without a hybrid pump
  # if you want to send analytics to control plane instead of pump, change analyticsConfigType to "rpc"
  analyticsConfigType: ""
```

Run the following command to deploy additional Gateways in namespace `another-namespace`.
```bash
helm install another-gateway tyk-helm/tyk-gateway --namespace another-namespace -f values.yaml
```

#### OpenTelemetry
To enable OpenTelemetry for Gateway set `gateway.opentelemetry.enabled` flag to true. It is disabled by default.

You can also configure connection settings for it's exporter. By default `grpc` exporter is enabled on `localhost:4317` endpoint.

 To enable TLS settings for the exporter, you can set `gateway.opentelemetry.tls.enabled` to true. 

### Pump Configurations

To enable Pump, set `global.components.pump` to true, and configure below inside `tyk-pump` section.

| Pump                      | Configuration                                                                                              |
|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------| 
| Prometheus Pump (Default) | Add the value `prometheus` to the `tyk-pump.pump.backend` entry, and add connection details for Prometheus under `tyk-pump.pump.prometheusPump`. |
| Mongo Pump                | Add `mongo` to `tyk-pump.pump.backend`, and add connection details for mongo under `global.mongo`.                                               |
| Mongo Selective Pump      | Add `mongo-selective` to `tyk-pump.pump.backend`, and add connection details for mongo under `global.mongo`.                                     |
| Mongo Aggregate Pump      | Add `mongo-aggregate` to `tyk-pump.pump.backend`, and add connection details for mongo under `global.mongo`.                                     |
| Postgres Pump             | Add `postgres` to `tyk-pump.pump.backend`, and add connection details for postgres under `global.postgres`.                                      |
| Postgres Aggregate Pump   | Add `postgres-aggregate` to `tyk-pump.pump.backend`, and add connection details for postgres under `global.postgres`.                            |
| Uptime Pump               | Set `tyk-pump.pump.uptimePumpBackend` to `mongo` or `postgres` or `""`                                                                           |
| Other Pumps               | Add the required environment variables in `tyk-pump.pump.extraEnvs`                                                                              |


{{< note success >}}
**Note**

For additional information on Tyk Pump configurations, refer to the 
[Setup Dashboard Analytics]({{<ref "tyk-pump/tyk-pump-configuration/tyk-pump-dashboard-config">}}) documentation.

To explore the list of supported backends for Tyk Pump, please visit [Pump Backends]({{<ref "tyk-stack/tyk-pump/other-data-stores">}}).
{{< /note >}}

#### Prometheus Pump
Add `prometheus` to `tyk-pump.pump.backend`, and add connection details for Prometheus under `tyk-pump.pump.prometheusPump`. 

We also support monitoring using Prometheus Operator. All you have to do is set `tyk-pump.pump.prometheusPump.prometheusOperator.enabled` to true.

This will create a _PodMonitor_ resource for your Pump instance.

```yaml
    # prometheusPump configures Tyk Pump to expose Prometheus metrics.
    # Please add "prometheus" to .Values.pump.backend in order to enable Prometheus Pump.
    prometheusPump:
      # host represents the host without port, where Tyk Pump serve the metrics for Prometheus.
      host: ""
      # port represents the port where Tyk Pump serve the metrics for Prometheus.
      port: 9090
      # path represents the path to the Prometheus collection. For example /metrics.
      path: /metrics
      # customMetrics allows defining custom Prometheus metrics for Tyk Pump.
      # It accepts a string that represents a JSON object. For instance,
      #
      # customMetrics: '[{"name":"tyk_http_requests_total","description":"Total of API requests","metric_type":"counter","labels":["response_code","api_name","method","api_key","alias","path"]},          {              "name":"tyk_http_latency",              "description":"Latency of API requests",              "metric_type":"histogram",              "labels":["type","response_code","api_name","method","api_key","alias","path"]          }]'
      customMetrics: ""
      # If you are using prometheus Operator, set the fields in the section below.
      prometheusOperator:
        # enabled determines whether the Prometheus Operator is in use or not. By default,
        # it is disabled.
        # Tyk Pump can be monitored with PodMonitor Custom Resource of Prometheus Operator.
        # If enabled, PodMonitor resource is created based on .Values.pump.prometheusPump.prometheusOperator.podMonitorSelector
        # for Tyk Pump.
        enabled: false
        # podMonitorSelector represents a podMonitorSelector of your Prometheus resource. So that
        # your Prometheus resource can select PodMonitor objects based on selector defined here.
        # Please set this field to the podMonitorSelector field of your monitoring.coreos.com/v1
        # Prometheus resource's spec.
        #
        # You can check the podMonitorSelector via:
        #   kubectl describe prometheuses.monitoring.coreos.com <PROMETHEUS_POD>
        podMonitorSelector:
          release: prometheus-stack
```

#### Mongo pump
To enable Mongo pump, add `mongo` to `tyk-pump.pump.backend`, and add connection details for mongo under `global.mongo`. See [Mongo Installation](#set-mongo-or-postgressql-connection-details-required) section above.

By default, it will enable Mongo Aggregate, Mongo Graph Pump and Mongo Selective Pump.


#### SQL pump
To enable SQL pump, add `postgres` to `tyk-pump.pump.backend`, and add connection details for postgres under `global.postgres`. See [PostgresSQL Installation](#set-mongo-or-postgressql-connection-details-required) section above.

By default, it will enable Postgres Aggregate, Postgres Graph Aggregate, SQL Pump and SQL graph pump.

#### Uptime Pump
Uptime Pump can be configured by setting `pump.uptimePumpBackend` in values.yaml file. It supports the following values
1. mongo: Used to set Mongo Pump for uptime analytics. Mongo Pump should be enabled.
2. postgres: Used to set Postgres Pump for uptime analytics. Postgres Pump should be enabled.
3. empty: Used to disable uptime analytics.

```yaml
    # uptimePumpBackend configures uptime Tyk Pump. ["", "mongo", "postgres"].
    # Set it to "" for disabling uptime Tyk Pump. By default, uptime pump is disabled.
    uptimePumpBackend: ""
```

#### Other Pumps
To setup other backends for pump, refer to this [document](https://github.com/TykTechnologies/tyk-pump/blob/master/README.md#pumps--back-ends-supported) and add the required environment variables in `pump.extraEnvs`


### Tyk Dashboard Configurations

#### Tyk Dashboard License (Required)

Tyk Dashboard License is required. It can be set up in `global.license.dashboard` or through secret `global.secrets.useSecretName`. The secret should contain a key called *DashLicense*.

```yaml
global:
  license:
    # The license key needed by Tyk Dashboard to work.
    #
    # NOTE: If you do not want to store license as a plain text in the file, you can use a Kubernetes secret
    # that stores the dashboard license. Please see `.global.secrets.useSecretName`.
    dashboard: ""
```

#### Enabling Dashboard TLS

Assuming that TLS certificates for the Tyk Dashboard are available in the Kubernetes Secret `tyk-dashboard-tls`,
follow these steps to enable TLS:

1. Set `global.tls.dashboard` to `true`.
2. Set `tyk-dashboard.dashboard.tls.secretName` to the name of the Kubernetes secret containing TLS certificates for the Tyk Dashboard, in this case, `tyk-dashboard-tls`.
3. Define certificate configurations in `tyk-dashboard.dashboard.tls.certificates`, which generates `TYK_DB_HTTPSERVEROPTIONS_CERTIFICATES` for the Tyk Dashboard.

Optional Steps, if needed:
- Modify the secret mount path on the Tyk Dashboard Pod via `tyk-dashboard.dashboard.tls.certificatesMountPath`.
- If necessary, either enable `insecureSkipVerify` via `tyk-dashboard.dashboard.tls.certificates`, or mount CA information through `tyk-dashboard.dashboard.extraVolumes` and `tyk-dashboard.dashboard.extraVolumeMounts`.
- If the `tyk-bootstrap` chart is used to bootstrap the Tyk Dashboard, ensure that it has certificates to send requests to the Tyk Dashboard or enable `insecureSkipVerify` in the `tyk-bootstrap` chart.
- If the Tyk Gateway connects to the Tyk Dashboard, confirm that the Tyk Gateway has appropriate certificates for connecting to the Tyk Dashboard

### Tyk Bootstrap Configurations

To enable bootstrapping, set `global.components.bootstrap` to `true`. It would run [tyk-k8s-bootstrap](https://github.com/TykTechnologies/tyk-k8s-bootstrap) to bootstrap `tyk-stack` and to create Kubernetes secrets that can be utilised in Tyk Operator and Tyk Developer Portal.

{{< note success >}}
**Note**

During bootstrapping, admin user needs to reset its password. It may be denied by Dashboard OPA rules if [OPA]({{<ref "/tyk-dashboard/open-policy-agent">}}) was enabled. Please disable OPA during the initial bootstrapping or set Dashboard configuration [TYK_DB_SECURITY_ALLOWADMINRESETPASSWORD]({{<ref "tyk-dashboard/configuration#securityallow_admin_reset_password">}}) to true.
{{< /note >}}

#### Bootstrapped Environments

If Tyk is already bootstrapped, the application will bypass the creation of the Tyk Organisation and Admin User, proceeding directly with the creation of Kubernetes Secrets.

Given that the Kubernetes Secrets require values for `TYK_AUTH` and `TYK_ORG`, it is essential to provide these values through the respective environment variables, called `TYK_K8SBOOTSTRAP_TYK_ADMIN_AUTH` for `TYK_AUTH` and `TYK_K8SBOOTSTRAP_TYK_ORG_ID` for `TYK_ORG`.

Ensure that these environment variables are set appropriately to `postInstall` hook for bootstrapped environments.

### Tyk Developer Portal Configurations

To enable Tyk Developer Portal, set `global.components.devPortal` to true, and configure below inside `tyk-dev-portal` section.

#### Tyk Developer Portal License (Required)

Tyk Developer Portal License is required. It can be set up in `tyk-dev-portal.license` or through secret `global.secrets.useSecretName`. The secret should contain a key called `DevPortalLicense`.

```yaml
tyk-dev-portal:
  # Tyk Developer Portal license.
  license: ""
```

#### Tyk Developer Portal Database

By default, Tyk Developer Portal use `sqlite3` to store portal metadata. If you want to use other SQL Database, please modify the section below.

```yaml
tyk-dev-portal:
  database:
    # This selects the SQL dialect to be used
    # The supported values are mysql, postgres and sqlite3
    dialect: "sqlite3"
    connectionString: "db/portal.db"
    enableLogs: false
    maxRetries: 3
    retryDelay: 5000
```

#### Storage Settings

Tyk Developer Portal supports different storage options for storing the portal's CMS assets such as images, theme files and Open API Specification files. Please see the [Developer Portal storage settings]({{<ref "product-stack/tyk-enterprise-developer-portal/deploy/configuration#portal-settings">}}) page for all the available options. 

If you use the file system as storage, please set `tyk-dev-portal.storage.type` to `fs`, and configure `tyk-dev-portal.storage.persistence` to mount an existing persistent volume to Tyk Developer Portal.

If you use [AWS S3](https://aws.amazon.com/s3/) as storage, please set `tyk-dev-portal.storage.type` to `s3`, and configure `tyk-dev-portal.storage.s3` section with credentials to access AWS S3 bucket.

If you use database as storage, please set `tyk-dev-portal.storage.type` to `db`, and configure the `tyk-dev-portal.database` section with database connection details.

```yaml
tyk-dev-portal:
  # Sensitive configuration of Portal could be set using k8s secret
  # You can set following fields:
  # - DevPortalLicense - Sets LicenseKey for Developer Portal
  # - DevPortalStorageConnectionString - Sets connectionString for Developer Portal
  # - DevPortalAwsAccessKeyId - Sets AWS S3 Access Key ID
  # - DevPortalAwsSecretAccessKey - Sets AWS S3 Secret Access Key
  useSecretName: ""
  # The hostname to bind the Developer Portal to.
  hostName: tyk-dev-portal.org
  # Developer Portal license.
  license: ""
  # Developer portal can be deployed as StatefulSet or as Deployment
  kind: StatefulSet
  storage:
    # User can set the storage type for portal.
    # Supported types: fs, s3, db
    type: "db"
    # Configuration values for using s3 as storage for Tyk Developer Portal
    # In case you want to provide the key ID and access key via secrets please
    # refer to the existing secret inside the helm chart or the
    # .Values.useSecretName field
    s3:
      awsAccessKeyid: your-access-key
      awsSecretAccessKey: your-secret-key
      region: sa-east-1
      endpoint: https://s3.sa-east-1.amazonaws.com
      bucket: your-portal-bucket
      acl: private
      presign_urls: true
    persistence:
      mountExistingPVC: ""
      storageClass: ""
      accessModes:
        - ReadWriteOnce
      size: 8Gi
      annotations: {}
      labels: {}
      selector: {}
  database:
    # This selects the SQL dialect to be used
    # The supported values are mysql, postgres and sqlite3
    dialect: "sqlite3"
    connectionString: "db/portal.db"
    enableLogs: false
    maxRetries: 3
    retryDelay: 5000
```

#### Other Configurations

Other [Developer Portal configurations]({{<ref "product-stack/tyk-enterprise-developer-portal/deploy/configuration">}}) can be set by using environment variables with `extraEnvs` fields, e.g.:

```yaml
tyk-dev-portal:
  extraEnvs:
  - name: PORTAL_LOG_LEVEL
    value: debug
```

### Tyk Operator Configurations

In order to enable installing Tyk Operator along-side Tyk Stack installation, please set `global.components.operator` to `true`.

All other configurations related to Tyk Operator are available under `tyk-operator` section of `values.yaml` file.

> Tyk Operator needs a cert-manager to be installed. Ensure that cert-manager is installed as described in the
> official documentation: [Installing Tyk Operator]({{<ref "tyk-stack/tyk-operator/installing-tyk-operator">}}).