Skip to main content
EditionDeployment Type
EnterpriseSelf-Managed, Hybrid

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.
    kubectl create secret generic tyk-dev-portal-conf -n ${NAMESPACE} \
    --from-literal=TYK_ORG=${TYK_ORG} \
    --from-literal=TYK_AUTH=${TYK_AUTH}
    
    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:
    Field NameDescription
    global.adminUser.email and global.adminUser.passwordSet portal admin username and email for bootstrapping
    global.secrets.devPortalEnable portal bootstrapping by providing secret name
    licenseTyk license key for your portal installation
    storage.typePortal storage type, e.g. fs, s3 and db
    image.tagDeveloper Portal version. You can get the latest version image tag from Docker Hub
    database.dialectPortal database dialect, e.g. mysql, postgres
    database.connectionStringConnection string to the Portal’s database, e.g. for the mysql dialect: admin:secr3t@tcp(tyk-portal-mysql:3306)/portal?charset=utf8mb4&parseTime=true
    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:
    helm install tyk-dev-portal tyk-helm/tyk-dev-portal -f values.yaml -n tyk
    
  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:
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  fsGroup: 2000

containerSecurityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  privileged: false
  readOnlyRootFilesystem: true
  seccompProfile:
    type: RuntimeDefault
  capabilities:
    drop:
      - ALL
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:
kubectl get jobs -n <namespace>
kubectl logs job/dev-portal-job-<release-name> -n <namespace>
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:
curl -X POST http://<portal-service>:<port>/portal-api/bootstrap \
  -H "Content-Type: application/json" \
  -d '{
    "username": "admin@example.com",
    "password": "your-password",
    "first_name": "Admin",
    "last_name": "User"
  }'
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.
TypeDescriptionNotes
dbAssets stored in the Portal databaseRecommended for Kubernetes. No PVC required.
s3Assets stored in an S3-compatible bucketSuitable for cloud or multi-replica deployments
fsAssets stored on the container filesystemRequires a PersistentVolumeClaim
For fs storage, configure a PVC using storage.persistence:
storage:
  type: fs
  persistence:
    storageClass: "standard"
    accessModes:
      - ReadWriteOnce
    size: 8Gi
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:
kind: Deployment
replicaCount: 3

storage:
  type: db  # or s3; both support concurrent access from multiple replicas
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.
    kubectl create secret generic tyk-enterprise-portal-conf -n ${NAMESPACE} \
    --from-literal=TYK_ORG=${TYK_ORG} \
    --from-literal=TYK_AUTH=${TYK_AUTH}
    
    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:
    Field NameDescription
    enterprisePortal.enabledEnable Portal installation
    enterprisePortal.bootstrapEnable Portal bootstrapping
    enterprisePortal.licenseTyk license key for your portal installation
    enterprisePortal.storage.typePortal database dialect, e.g mysql, postgres
    enterprisePortal.storage.connectionStringConnection string to the Portal’s database, e.g for the mysql dialect: admin:secr3t@tcp(tyk-portal-mysql:3306)/portal?charset=utf8mb4&parseTime=true
    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:
    helm upgrade tyk-pro tyk-helm/tyk-pro -f values.yaml -n tyk
    
    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+.