Tyk Stack Chart - Tyk Documentation

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 cluster using the Helm package manager.

Component	Enabled by Default	Flag
Tyk Gateway	true	n/a
Tyk Dashboard	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. For quick start guide, please see Quick Start with Helm Chart and PostgreSQL or Quick Start with Helm Chart and MongoDB.

Prerequisites

Kubernetes 1.19+
Helm 3+
Redis should already be installed or accessible by the gateway and dashboard.
MongoDB or PostgreSQL should already be installed or accessible by dashboard. Please consult the list of supported versions 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:

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. At a minimum, modify values.yaml for the following settings:

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

Developer Portal License

Then just run:

helm install tyk-stack tyk-helm/tyk-stack -n tyk --create-namespace -f values.yaml

Uninstalling The Chart

helm uninstall tyk-stack -n tyk

This removes all the Kubernetes components associated with the chart and deletes the release.

Upgrading Chart

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

Configuration

To list all configurable options with detailed comments:

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 for examples. To configure Tyk components, users can utilize both config files and environment variables. 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. 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.

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:

tyk-gateway:
  gateway:
    extraEnvs:
    - name: TYK_GW_LOGLEVEL
      value: debug

An example is listed below for setting extra environment variable using ConfigMap data, using gateway:

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, using gateway:

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.

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. Copy the following commands to add it:

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

Please make sure you are installing Redis versions that are supported by Tyk. Please refer to Tyk docs to get list of supported versions.

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 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 or Official Redis installation guides 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.

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

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

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.

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.

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:[email protected]: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

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

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.

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. 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 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.

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

AdminSecret The global.secrets.AdminSecret field sets a 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.

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:

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:

global:  
  mongo:
    connectionURLSecret:
       name: "yourSecret"
       keyName: "mongoConnectionURLkey"

PostgreSQL:

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. Please check Tyk Release notes 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:

Create a TLS secret using your cert and key pair.
Set global.tls.gateway to true.
Set tyk-gateway.gateway.tls.useDefaultTykCertificate to false.
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.

   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:

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:

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.

    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 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.

    # 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.

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.

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 documentation.To explore the list of supported backends for Tyk Pump, please visit Pump Backends.

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.

    # 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 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 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

mongo: Used to set Mongo Pump for uptime analytics. Mongo Pump should be enabled.
postgres: Used to set Postgres Pump for uptime analytics. Postgres Pump should be enabled.
empty: Used to disable uptime analytics.

    # 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 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.

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:

Set global.tls.dashboard to true.
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.
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, set global.components.bootstrap to true. It would run 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 was enabled. Please disable OPA during the initial bootstrapping or set Dashboard configuration TYK_DB_SECURITY_ALLOWADMINRESETPASSWORD 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.

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, 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.

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 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 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.

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 can be set by using environment variables with extraEnvs fields, e.g.:

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 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.

Overview

Getting Started

Managing APIs

Security in Tyk

Deploy Tyk

Reference

Developer Support

​What components are deployed with Tyk Stack Chart?

​Prerequisites

​Tyk Stack Installations

​Installing The Chart

​Uninstalling The Chart

​Upgrading Chart

​Configuration

​Bootstrapping

​Setting Environment Variables

​Set Redis Connection Details (Required)

​Set Mongo or PostgresSQL Connection Details (Required)

​Protect Confidential Fields with Kubernetes Secrets

​Gateway Configurations

​Update Tyk Gateway Version

​Enabling TLS

​Enabling gateway autoscaling

​Accessing Gateway

​Sharding

​Deploy additional gateway groups

​OpenTelemetry

Liveness and readiness probes

​Pump Configurations

​Prometheus Pump

​Mongo pump

​SQL pump

​Uptime Pump

​Other Pumps

​Tyk Dashboard Configurations

​Tyk Dashboard License (Required)

​Enabling Dashboard TLS

​Audit Log Configurations

OPA Configurations

​Tyk Bootstrap Configurations

​Bootstrapped Environments

​Tyk Developer Portal Configurations

​Tyk Developer Portal License (Required)

​Tyk Developer Portal Database

​Storage Settings

​Other Configurations

​Tyk Operator Configurations

What components are deployed with Tyk Stack Chart?

Prerequisites

Tyk Stack Installations

Installing The Chart

Uninstalling The Chart

Upgrading Chart

Configuration

Bootstrapping

Setting Environment Variables

Set Redis Connection Details (Required)

Set Mongo or PostgresSQL Connection Details (Required)

Protect Confidential Fields with Kubernetes Secrets

Gateway Configurations

Update Tyk Gateway Version

Enabling TLS

Enabling gateway autoscaling

Accessing Gateway

Sharding

Deploy additional gateway groups

OpenTelemetry

Pump Configurations

Prometheus Pump

Mongo pump

SQL pump

Uptime Pump

Other Pumps

Tyk Dashboard Configurations

Tyk Dashboard License (Required)

Enabling Dashboard TLS

Audit Log Configurations

Tyk Bootstrap Configurations

Bootstrapped Environments

Tyk Developer Portal Configurations

Tyk Developer Portal License (Required)

Tyk Developer Portal Database

Storage Settings

Other Configurations

Tyk Operator Configurations