Tyk Control Plane Chart (Beta)

The tyk-control-plane provides the default deployment of Tyk control plane 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 Control Plane Chart?

It includes:

• Tyk Gateway, an Open Source Enterprise API Gateway (supporting REST, GraphQL, TCP and gRPC protocols).
• Tyk Dashboard, a license based component that provides a graphical management interface and analytics platform for Tyk.
• Tyk MDCB, a license based component that performs management and synchronisation of distributed clusters of Tyk API Gateways.
• Tyk Pump, an analytics purger that moves the data generated by your Tyk nodes to any back-end.
• Tyk Developer Portal, a full-fledged CMS-like system for API providers to publish, monetise and drive the adoption of APIs.

Learn more about Tyk control plane at MDCB components.

By default, this chart installs the following components as sub-charts on a Kubernetes cluster using the Helm package manager.

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

Also, you can set the version of each component through image.tag. You could find the list of version tags available from Docker hub.

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.

Tyk Control Plane Installations

Installing The Chart

To install the chart from Helm repository in namespace tyk with the release name tyk-control-plane, issue the following commands:

helm repo add tyk-helm https://helm.tyk.io/public/helm/charts/
helm repo update
helm show values tyk-helm/tyk-control-plane --devel > 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:

1. Set Redis connection details
2. Set Mongo or PostgreSQL connection details
3. Tyk Dashboard License
4. Tyk MDCB License

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

5. Tyk Developer Portal License

Then just run:

helm install tyk-control-plane tyk-helm/tyk-control-plane -n tyk --create-namespace -f values.yaml --devel

Uninstalling The Chart

helm uninstall tyk-control-plane -n tyk

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

Upgrading Chart

helm upgrade tyk-control-plane tyk-helm/tyk-control-plane -n tyk -f values.yaml --devel

Configuration

To get all configurable options with detailed comments, issue the following command:

helm show values tyk-helm/tyk-control-plane --devel > 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.

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 or Tyk’s simple-redis to install chart for POC purpose.

Set the following values after installing Redis:

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

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.

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 PostgreSQL Connection Details (Required)

If you have already installed MongoDB or PostgreSQL, you can set the connection details in global.mongo and global.postgres section of values file respectively.

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

Mongo Installation

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

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

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
   mongoURL: <MongoDB address>

   # 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

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

PostgreSQL Installation

helm install tyk-postgres bitnami/postgresql --set "auth.database=tyk_analytics" -n tyk --version 14.2.4

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

global:
  # Postgres connection string parameters.
  postgres:
    # host corresponds to the host name of postgres
    host: tyk-postgres-postgresql.tyk.svc
    # port corresponds to the port of postgres
    port: 5432
    # user corresponds to the user of postgres
    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 postgres
    database: tyk_analytics
    # sslmode corresponds to if postgres 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 Admin

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

All admin credentials can also be set through Kubernetes secret.

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.

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.

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.

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.

Dashboard License

In order to refer to a Tyk Dashboard license through 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 to a Tyk Developer Portal license through 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 to a Tyk Developer Portal’s admin password through 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 to a Tyk Developer Portal connection string to the selected database through a Kubernetes secret, please use tyk-dev-portal.useSecretName, where the secret should contain a key called DevPortalStorageConnectionString.

Tyk Developer Portal AWS S3 Access Key ID

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

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.

Redis Password

The Redis password can also be provided via a secret. Store the Redis password in Kubernetes secret and refer to this secret via global.redis.passSecret.name and global.redis.passSecret.keyName field, as follows:

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

MongoDB or Postgres connection strings

Storage connection strings can also be provided via a secret.

For MongoDB, suppose you have a secret named yourSecret and you have the mongo connection URL stored in key mongoConnectionURLkey. Store the connection string in Kubernetes secret and refer to this secret via global.mongo.connectionURLSecret.name and global.mongo.connectionURLSecret.keyName field, as follows:

• MongoDB:

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

For Postgres, suppose you have a secret named yourSecret and you have the postgres connection string stored in key postgreConnectionURLkey. Store the connection string in Kubernetes secret and refer to this secret via global.postgres.connectionStringSecret.name and global.postgres.connectionStringSecret.keyName field, as follows:

• Postgres:

global:
  postgres:
    connectionStringSecret:
       name: "yourSecret"
       keyName: "postgreConnectionURLkey"

Gateway Configurations

Configure the following details below, inside the tyk-gateway section.

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

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

Pump Configurations

To enable Pump, set global.components.pump to true and configure the following parameters included below inside the tyk-pump section.

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:

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.

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

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 bootstrap app can validate certificate of 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 MDCB Configurations

Tyk MDCB License (Required)

Tyk MDCB requires a license to be set at tyk-mdcb.mdcb.license. This field is mandatory and must be configured.

To enhance security and avoid storing plaintext values for the MDCB license directly in the Helm value file, an alternative approach is available. You can store the license in a Kubernetes Secret and reference it externally.

Set the license in the Kubernetes Secret and provide the secret’s name through tyk-mdcb.mdcb.useSecretName. The Secret must contain a key named MDCBLicense.

Tyk MDCB Listen Port

The tyk-mdcb.mdcb.listenPort field represents a RPC port which worker Tyk Gateways will connect to. Setting tyk-mdcb.mdcb.listenPort field opens a port on MDCB container and MDCB service targets this port. It is used to set TYK_MDCB_LISTENPORT

Tyk MDCB Health Check Port

The health check port for Tyk MDCB can be configurable via the tyk-mdcb.mdcb.probes.healthCheckPort field. This port lets MDCB allow standard health checks.

It also defines the path for liveness and readiness probes. It is used to set TYK_MDCB_HEALTHCHECKPORT

Tyk Bootstrap Configurations

To enable bootstrapping, set global.components.bootstrap to true. It would run tyk-k8s-bootstrap to bootstrap tyk-control-plane and to create Kubernetes secrets that can be utilised in Tyk Operator and Tyk Developer Portal.

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.

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 a different 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 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