> ## Documentation Index > Fetch the complete documentation index at: https://tyk.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # Tyk Stack Chart > Install and configure Tyk Stack Chart 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, monetize 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 Pump | true | 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](/tyk-self-managed/install/kubernetes#tyk-stack-postgresql) or [Quick Start with Helm Chart and MongoDB](/tyk-self-managed/install/kubernetes#tyk-stack-mongodb). ## Prerequisites * [Kubernetes 1.19+](https://kubernetes.io/docs/setup/) * [Helm 3+](https://helm.sh/docs/intro/install/) * [Redis](/tyk-configuration-reference/redis-cluster-sentinel) 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](/api-management/dashboard-configuration#supported-database) that are compatible with Tyk. If you want to enable Tyk Developer Portal, please use PostgreSQL. MongoDB is not supported in Developer Portal. ## Tyk Stack Installations ### Installing The Chart To install the chart from Helm repository in namespace `tyk` with the release name `tyk-stack`: ```bash theme={null} 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 theme={null} helm install tyk-stack tyk-helm/tyk-stack -n tyk --create-namespace -f values.yaml ``` ### Uninstalling The Chart ```bash theme={null} helm uninstall tyk-stack -n tyk ``` This removes all the Kubernetes components associated with the chart and deletes the release. ### Upgrading Chart ```bash theme={null} helm upgrade tyk-stack tyk-helm/tyk-stack -n tyk -f values.yaml ``` ## Configuration To list all configurable options with detailed comments: ```bash theme={null} 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](/tyk-oss-gateway/configuration). ### Bootstrapping By default, the chart executes a bootstrapping job immediately after installation. This process ensures the presence of a valid dashboard license and initializes key components such as tyk-dashboard, tyk-portal, and tyk-operator, enabling them for immediate use. The bootstrapping job uses three distinct applications acting as Helm chart hooks: | **Bootstrapping Component** | **Description** | | :-------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `bootstrap-pre-install` | - Runs as a pre-install hook.
- Validates the Tyk Dashboard license key to ensure proper installation prerequisites. | | `bootstrap-post-install` | - Executes post-installation.
- Sets up an organization and admin user in the Tyk Dashboard.
- Creates Kubernetes secrets required by Tyk Operator and Tyk Enterprise Portal.
**Note**: If an existing organization and admin user are found in the database, the bootstrapping job will not set up a new organization and user. The Kubernetes secrets will not contain the expected Org ID or API key. Please update the Secret with existing credentials in this case. | | `bootstrap-pre-delete` | - Functions as a pre-delete hook.
- Cleans up resources, ensuring no residual configurations remain post-uninstallation. | Key Notes on Bootstrapping: * Bootstrapping is triggered **only during** a `helm install` and does not run during a `helm upgrade`. * If `global.components.bootstrap` is set to `false`, only the dashboard license check will be performed. Handling Bootstrapping Failures: * If the bootstrapping process fails, check the logs from the bootstrap pods to diagnose the issue. * Once reviewed, you can safely delete the bootstrap pods. * To re-trigger the bootstrapping process after a failure, you must run `helm uninstall` and start the installation process anew. ### 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 theme={null} 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 theme={null} 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 theme={null} 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](/tyk-configuration-reference/kv-store). ### 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 theme={null} helm upgrade tyk-redis oci://registry-1.docker.io/bitnamicharts/redis -n tyk --create-namespace --install --version 19.0.2 --set image.repository=bitnamilegacy/redis ``` Please make sure you are installing Redis versions that are supported by Tyk. Please refer to Tyk docs to get list of [supported versions](/tyk-self-managed/install#redis). 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. 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. ```bash theme={null} 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 theme={null} helm repo add bitnami https://charts.bitnami.com/bitnami helm install tyk-mongo bitnami/mongodb --set "replicaSet.enabled=true" -n tyk --version 15.1.3 --set image.repository=bitnamilegacy/mongodb ``` Bitnami MongoDB image is not supported on darwin/arm64 architecture. Then follow notes from the installation output to get connection details and update them in `values.yaml` file. Please make sure you are installing MongoDB versions that are supported by Tyk. Please refer to Tyk docs to get list of [supported versions](/api-management/dashboard-configuration#supported-database). 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. 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 theme={null} 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 theme={null} helm repo add bitnami https://charts.bitnami.com/bitnami helm install tyk-postgres bitnami/postgresql --set "auth.database=tyk_analytics" -n tyk --version 12.12.10 --set image.repository=bitnamilegacy/postgresql ``` Follow the notes from the installation output to get connection details. Please make sure you are installing PostgreSQL versions that are supported by Tyk. Please refer to Tyk docs to get list of [supported versions](/api-management/dashboard-configuration#supported-database). ```yaml theme={null} 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. 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. ***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](/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 theme={null} global: secrets: APISecret: CHANGEME useSecretName: "mysecret" # where mysecret includes `APISecret` key with the desired value. ``` ***AdminSecret*** The `global.secrets.AdminSecret` field sets a [secret](/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 theme={null} global: secrets: useSecretName: "mysecret" # where mysecret includes `AdminSecret` key with the desired value. ``` Once `global.secrets.useSecretName` is declared, it takes precedence over `global.secrets.APISecret` and `global.secrets.AdminSecret`. ***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`. If `tyk-dev-portal.useSecretName` is in use, please add all keys mentioned to the secret. ***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`. If `tyk-dev-portal.useSecretName` is in use, please add all keys mentioned to the secret. ***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`. If `tyk-dev-portal.useSecretName` is in use, please add all keys mentioned to the secret. ***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 theme={null} 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 theme={null} global: mongo: connectionURLSecret: name: "yourSecret" keyName: "mongoConnectionURLkey" ``` * PostgreSQL: ```yaml theme={null} global: postgres: connectionStringSecret: name: "yourSecret" keyName: "postgreConnectionURLkey" ``` ***Tyk Operator License*** It can be configured via `global.license.operator` as a plain text or Kubernetes secret which includes `OperatorLicense` key in it. Then, this secret must be referenced via `global.secrets.useSecretName`. Note: If you are using `global.secrets.useSecretName`, you must configure the operator license in the referenced Kubernetes secret. `global.license.operator` will not be used in this case. ### 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](/developer-support/release-notes/gateway) 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 `global.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 theme={null} 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 utilization at 60%, scaling between 1 and 3 instances. To customize those values you can modify the tyk-gateway section of the `values.yaml` file as shown below: ```yaml theme={null} 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 theme={null} 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 theme={null} 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](/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 theme={null} # 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 theme={null} 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 theme={null} 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. #### Liveness and readiness probes Gateway liveness probes can be customised via `gateway.livenessProbe` field. All fields from PodLivenessProbe object can be added here. If set to empty or nil, the default health check on /health will be performed. Gateway readiness probes can be customised via `gateway.readinessProbe` field. All fields from PodReadinessProbe object can be added here. If set to empty or nil, the default health check on /health will be performed. ### 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` | For additional information on Tyk Pump configurations, refer to the [Setup Dashboard Analytics](/api-management/tyk-pump#setup-dashboard-analytics) documentation. To explore the list of supported backends for Tyk Pump, please visit [Pump Backends](/api-management/tyk-pump#external-data-stores). #### 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 theme={null} # 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 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 theme={null} # 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 theme={null} 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 #### Audit Log Configurations You can manage audit logging for Tyk Dashboard via `auditLogs`: * `auditLogs.enabled`: Enables or disables audit logging. It sets corresponding Dashboard environment variable `TYK_DB_AUDIT_ENABLED`. Disabled by default. * `auditLogs.type`: Specifies the storage type for audit logs (`db` or `file`). It sets corresponding Dashboard environment variable `TYK_DB_AUDIT_STORETYPE`. Set to `file` by default. * `auditLogs.format`: Defines the format of audit log files (`json` or `text`). It sets corresponding Dashboard environment variable `TYK_DB_AUDIT_FORMAT`. Set to `text` by default. * `auditLogs.path`: Sets the path to the audit log file. It sets corresponding Dashboard environment variable `TYK_DB_AUDIT_PATH`. Set to "" by default. * `auditLogs.enableDetailedRecording`: Enables detailed logging, including HTTP requests (headers only) and full HTTP responses. It sets corresponding Dashboard environment variable `TYK_DB_AUDIT_DETAILEDRECORDING`. Disabled by default. #### OPA Configurations You can manage OPA (Open Agent Policy) for Tyk Dashboard via `opa`: * `opa.enabled`: Enables OPA support. It sets corresponding Dashboard environment `TYK_DB_SECURITY_OPENPOLICY_ENABLED`. Disabled by default. * `opa.debug`: Activates OPA debug mode for detailed logging of policy execution. It sets corresponding Dashboard environment `TYK_DB_SECURITY_OPENPOLICY_DEBUG`. Disabled by default. * `opa.api`: Enables OPA API mode to manage policies via the Dashboard API. It sets corresponding Dashboard environment `TYK_DB_SECURITY_OPENPOLICY_ENABLEAPI`. Disabled by default. * `opa.allowAdminPasswordReset`: Required if OPA is enabled with its default policies. It sets corresponding Dashboard environment `TYK_DB_SECURITY_ALLOWADMINRESETPASSWORD`. Enabled by default. ### Tyk Bootstrap Configurations To enable [bootstrapping](#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 utilized in Tyk Operator and Tyk Developer Portal. During bootstrapping, admin user needs to reset its password. It may be denied by Dashboard OPA rules if [OPA](/api-management/dashboard-configuration#extend-permissions-using-open-policy-agent-opa) was enabled. Please disable OPA during the initial bootstrapping or set Dashboard configuration [TYK\_DB\_SECURITY\_ALLOWADMINRESETPASSWORD](/tyk-dashboard/configuration#security-allow_admin_reset_password) to true. #### Bootstrapped Environments If Tyk is already bootstrapped, the application will bypass the creation of the Tyk Organization 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 theme={null} tyk-dev-portal: # Tyk Developer Portal license. license: "" ``` #### Tyk Developer Portal Database Tyk no longer supports SQLite as of Tyk 5.7.0. To avoid disruption, please transition to [PostgreSQL](/planning-for-production/database-settings#postgresql), [MongoDB](/planning-for-production/database-settings#mongodb), or one of the listed compatible alternatives. 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 theme={null} 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](/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 theme={null} 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](/product-stack/tyk-enterprise-developer-portal/deploy/configuration) can be set by using environment variables with `extraEnvs` fields, e.g.: ```yaml theme={null} tyk-dev-portal: extraEnvs: - name: PORTAL_LOG_LEVEL value: debug ``` ### Tyk Operator Configurations Tyk Operator is a licensed component that requires a valid key for operation. Please refer to the [Tyk Operator Installation Guide](/tyk-stack/tyk-operator/installing-tyk-operator) for detailed information on the installation and upgrade processes. Prior to installing Tyk Operator, ensure that a valid license key is provided by setting `global.license.operator` field in values.yaml file. You can set license key via a Kubernetes secret using `global.secrets.useSecretName` field. The secret should contain a key called `OperatorLicense`. 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](/tyk-stack/tyk-operator/installing-tyk-operator).