Skip to main content

Compatible Kubernetes Versions

1.33.x, 1.34.x, 1.35.x

Prerequisites

Running on Podman, containerd, or another container runtime? See Container Runtimes.

Tyk Stack (New Helm Chart)

There are two ways to install the portal on Kubernetes:
  1. As part of Tyk Self-Managed - Enable global.components.devPortal during Tyk Self-Managed deployment using the tyk-stack chart
  2. Standalone installation - Use the tyk-dev-portal Helm chart (described below)
This section provides a step-by-step instruction for installing the Tyk Developer Portal as standalone component using the new helm chart.

Instructions

  1. Create the tyk-dev-portal-conf secret Make sure the tyk-dev-portal-conf secret exists in your namespace. This secret will automatically be generated if Tyk Dashboard instance was bootstrapped with tyk-boostrap component chart and bootstrap.devPortal was set to true in the values.yaml. If the secret does not exist, you can create it by running the following command.
    The fields TYK_ORG and TYK_AUTH are the Tyk Dashboard Organization ID and the Tyk Dashboard API Access Credentials respectively. These can be obtained under your profile in the Tyk Dashboard.
  2. Config settings You must set the following values in the values.yaml or with --set {field-name}={field-value} using the helm upgrade command: In addition to values.yaml, you can also define the environment variables described in the configuration section to further customize your portal deployment. These environment variables can also be listed as a name value list under the extraEnvs section of the helm chart.
  3. Launch the portal using the helm chart Run the following command to update your infrastructure and install the developer portal:
  4. Bootstrapping the Developer Portal Follow the bootstrapping section of the documentation to bootstrap the portal via the UI or the admin API.

Configuration

For the full list of configurable values, refer to the tyk-stack chart guide. The sections below cover common production configuration scenarios.
Note: Helm chart supports Developer Portal v1.2.0+.

Pod Security Context

The chart ships with hardened defaults for the Portal pod that satisfy the Kubernetes Restricted Pod Security Standard:
Override these in your values.yaml to match your cluster’s PSS policy.
Bootstrap job security context limitationThe bootstrap job does not inherit securityContext or containerSecurityContext from values.yaml. On clusters enforcing PSS Restricted or Baseline profiles, the job will fail with a security policy violation.Workaround: Disable the automatic bootstrap and run it manually after deployment. See Bootstrap Job below.

Bootstrap Job

The bootstrap job runs once after helm install. It waits for the Portal pod to become ready, then calls POST /portal-api/bootstrap to create the bootstrap admin (API Owner) user. The Portal blocks its startup sequence until this call succeeds. Verify bootstrap completed:
A successful run logs: API call completed. To disable automatic bootstrap and bootstrap manually (required on clusters with strict Pod Security Standards):
  1. Set global.components.bootstrap: false in your values.yaml and deploy.
  2. Wait for the Portal pod to be ready, then send the bootstrap request:
Once the call succeeds, the Portal detects the new user and completes its startup sequence.

Storage

The storage.type setting controls where the portal stores assets (themes, images, OpenAPI specs). Session storage is always backed by the Portal database, regardless of this setting. For fs storage, configure a PVC using storage.persistence:
storage.type: fs with multiple replicas requires a storage class that supports ReadWriteMany. Use db or s3 to avoid this constraint.

Scaling and Replicas

The default kind: StatefulSet is suited for single-pod deployments. To run multiple replicas, switch to Deployment:
Portal sessions are stored in the Portal database. All replicas share the same session store automatically via the shared database connection. No sticky sessions or additional session store configuration is required.

Troubleshooting

For bootstrap job failures, crash-loops, database connectivity issues, and license key errors, see Kubernetes Bootstrap Failures.

Legacy Helm Chart

NoteIt is recommended to use new helm charts instead of legacy charts. Guide for new charts can be found here
This section provides a clear and concise, step-by-step recipe for installing the Tyk Developer Portal using legacy helm chart.

Instructions

  1. Create the tyk-enterprise-portal-conf secret Make sure the tyk-enterprise-portal-conf secret exists in your namespace. This secret will automatically be generated during the Tyk Dashboard bootstrap if the dash.enterprisePortalSecret value is set to true in the values.yaml. If the secret does not exist, you can create it by running the following command.
    Where TYK_ORG and TYK_AUTH are the Tyk Dashboard Organization ID and the Tyk Dashboard API Access Credentials respectively. Which can be obtained under your profile in the Tyk Dashboard.
  2. Config settings You must set the following values in the values.yaml or with --set {field-name}={field-value} with the helm upgrade command: In addition to values.yaml, you can also define the environment variables described in the configuration section to further customize your portal deployment. These environment variables can also be listed as a name value list under the extraEnvs section of the helm chart.
  3. Launch the portal using the helm chart Run the following command to update your infrastructure and install the developer portal:
    In case this is the first time you are launching the portal, it will be necessary to bootstrap it before you can use it. For detailed instructions, please refer to the bootstrapping documentation.
Note: Helm chart supports Developer Portal v1.2.0+.