Tyk

Overview

Tyk is an open-source API gateway that fronts your APIs with authentication, rate limiting, quotas and analytics. This template deploys the open-source Tyk Gateway as a stateless, autoscaling workload whose API definitions and policies come from Control Plane secrets you control, backed by the bundled Redis template running Redis with Sentinel as the token, rate-limit and quota store. There is no dashboard: APIs are defined as JSON files and keys are managed through the Gateway Control API.

This template deploys into an existing GVC that you already have — it does not create or manage a GVC. Every workload below runs in each location of that GVC.

What Gets Created

Resource	Name	Purpose	Optional
Workload	`RELEASE_NAME-tyk-api-gateway`	Tyk Gateway serving proxied APIs and the Gateway Control API under `/tyk/` on one HTTP port, `8080` by default (standard, autoscales 1 to 3 replicas on CPU)	—
Workload	`RELEASE_NAME-redis`	Redis token, rate-limit, quota and analytics store (stateful, 2 replicas, port `6379`)	—
Workload	`RELEASE_NAME-sentinel`	Redis Sentinel for automatic Redis failover; the gateway connects through Sentinel (stateful, 3 replicas, port `26379`)	—
Volume set	`RELEASE_NAME-redis-vs`, `RELEASE_NAME-sentinel-vs`	Redis data and Sentinel state (10 GiB per replica to start, daily snapshots kept 7 days)	`redis.redis.persistence.enabled`, `redis.sentinel.persistence.enabled` (both on by default)
Secret	`RELEASE_NAME-redis-auth-password`, `RELEASE_NAME-sentinel-auth-password`	Redis and Sentinel passwords, created by the chart from `redis.redis.auth.password.value` and `redis.sentinel.auth.password.value`	`auth.password.enabled` (on by default)
Secret	`RELEASE_NAME-redis-config`, `RELEASE_NAME-sentinel-config`	Redis and Sentinel configuration	—
Identity / Policy	`RELEASE_NAME-tyk-identity`, `RELEASE_NAME-tyk-api-gateway-policy`	`reveal` on exactly the secrets the gateway reads: your admin, API and policy secrets, and the Redis and Sentinel password secrets	—
Identity / Policy	`RELEASE_NAME-redis-identity`, `RELEASE_NAME-redis-policy`, `RELEASE_NAME-sentinel-identity`, `RELEASE_NAME-sentinel-policy`	The Redis tier’s own identities and policies	—

The admin API key, your API definitions and your policies are prerequisite secrets you create yourself; the chart references them by name and never creates, modifies or deletes them.

Prerequisites

Three secrets are referenced by name, and each one named in your values must exist before you install. Secrets are org-level, so no --gvc flag is involved.

Create the admin API key secret (required)

An opaque secret holding the key for the Gateway Control API under /tyk/, sent as the X-Tyk-Authorization header. Whoever holds it can create, list and revoke every API key on the gateway, so generate a strong random value:

printf '%s' "$(openssl rand -hex 32)" | cpln secret create-opaque --name ADMIN_SECRET_NAME --encoding plain -f -

Set adminSecretName to this name. The chart refuses to render without it.

Create the API definitions secret

A dictionary secret whose keys are *.json filenames and whose values are Tyk API definitions, mounted at /opt/tyk-gateway/apps. Each definition’s proxy.target_url points at the upstream it fronts — for a workload in the same GVC, use its fully qualified internal address. Because the values are multi-line JSON, write a manifest:

kind: secret
name: APIS_SECRET_NAME
type: dictionary
data:
  app1.json: >-
    { "api_id": "app1", "name": "app1", "org_id": "default", "use_keyless":
    true, "use_jwt": false, "disable_rate_limit": true, "definition": {
    "location": "header", "key": "version" }, "version_data": { "not_versioned":
    true, "versions": { "Default": { "name": "Default", "use_extended_paths":
    true } } }, "proxy": { "listen_path": "/app1", "target_url":
    "http://app1.GVC_NAME.cpln.local:8080", "strip_listen_path": true },
    "active": true}

Then apply it:

cpln apply -f apis.yaml

Set apiSecretName to this name. Setting it to "" omits the mount — but then the gateway serves the demo API baked into the image instead of nothing (see Troubleshooting).

Create the policies secret

An opaque secret with encoding plain, holding a single JSON object of policies keyed by policy ID, mounted at /opt/tyk-gateway/policies/policies.json:

kind: secret
name: POLICIES_SECRET_NAME
type: opaque
data:
  encoding: plain
  payload: |-
    {
      "app1-rate-limit": {
        "org_id": "default",
        "active": true,
        "rate": 20,
        "per": 100,
        "quota_max": 0,
        "quota_renewal_rate": 0,
        "quota_remaining": 0,
        "access_rights": {
          "app1": {
            "api_id": "app1",
            "api_name": "app1",
            "versions": ["Default"]
          }
        }
      }
    }

cpln apply -f policies.yaml

Set policySecretName to this name, or set it to "" to run with no policies.

Choose the Redis and Sentinel passwords

The bundled Redis serves only this gateway, so its passwords are Helm values the chart turns into secrets — nothing to create. They ship as the placeholders change-me-tyk-redis and change-me-tyk-sentinel and are used exactly as written, so set redis.redis.auth.password.value and redis.sentinel.auth.password.value to values of your own.

A missing prerequisite secret wedges the install rather than failing it. apiSecretName and policySecretName default to the names my-tyk-apis and my-tyk-policies, so they must exist too unless you set them to "". cpln helm install reports success and every resource is created, but the gateway container never starts — so cpln logs returns zero lines. The only place the missing secret is named is status.versions[].message:

cpln workload get-deployments RELEASE_NAME-tyk-api-gateway --gvc GVC_NAME -o yaml

The message reads

The secret <name> no longer exists. Workload updates are paused until the secret is added or the reference to the secret removed.

It is get-deployments — plain cpln workload get has no versions key. Create the missing secret and the deployment recovers on its own after several minutes, or run cpln workload force-redeployment RELEASE_NAME-tyk-api-gateway --gvc GVC_NAME to skip the wait.

Installation

Once the secrets exist, install the template into your GVC, naming the secrets and replacing the two password placeholders:

cpln helm install RELEASE_NAME oci://ghcr.io/controlplane-com/templates/tyk \
  --version 1.3.0 --gvc GVC_NAME \
  --set adminSecretName=ADMIN_SECRET_NAME \
  --set apiSecretName=APIS_SECRET_NAME \
  --set policySecretName=POLICIES_SECRET_NAME \
  --set redis.redis.auth.password.value='YOUR-STRONG-REDIS-PASSWORD' \
  --set redis.sentinel.auth.password.value='YOUR-STRONG-SENTINEL-PASSWORD'

Prefer a values file (-f) over --set for the passwords if you do not want them in your shell history.

UI

Browse, install, and manage templates visually

CLI

Manage templates from your terminal

Terraform

Declare templates in your Terraform configurations

Pulumi

Declare templates in your Pulumi programs

Configuration

Image and Port

image: tykio/tyk-gateway:v5.10.0

listenPort: 8080 # REQUIRED - the port the gateway listens on

The chart refuses to render if listenPort is one of the container ports Control Plane reserves.

API Definitions and Policies

adminSecretName: my-tyk-admin-secret # REQUIRED - opaque secret (encoding: plain) holding the admin API key

apiSecretName: my-tyk-apis # dictionary secret holding your API definition JSON files; "" = serve the image's demo APIs
policySecretName: my-tyk-policies # opaque secret holding your policies JSON; "" = no policies

Definitions and policies are read when the gateway starts. To change them, see Updating API Definitions and Policies.

Master Keys

allowMasterKeys: false # true lets a key created with no access_rights reach EVERY API on this gateway

With the default false, every key created through /tyk/keys must carry an access_rights entry naming the APIs it may reach. Requests that omit it are refused — see Troubleshooting for the exact responses.

Resources and Autoscaling

resources:
  cpu: 50m
  memory: 128Mi

autoscaling:
  maxScale: 3
  metric: cpu
  minScale: 1
  scaleToZeroDelay: 300
  target: 100

multiZone: false # OPTIONAL - Deploys replicas across multiple zones (confirm availability in your location)

Access

externalAccess: false # true publishes the gateway — INCLUDING its /tyk admin API — to the internet
internalAccess: # OPTIONAL - Sets the internal firewall scope
  type: same-gvc # options: none, same-gvc, same-org, workload-list
  workloads: [] # used with workload-list, e.g. //gvc/GVC_NAME/workload/WORKLOAD_NAME

Type	Description
`none`	No internal access allowed
`same-gvc`	Allow access from all workloads in the same GVC
`same-org`	Allow access from all workloads in the same organization
`workload-list`	Allow access only from the workloads listed in `internalAccess.workloads`

The chart refuses to render with externalAccess: false and internalAccess.type: none together, since nothing could reach the gateway. An access change takes up to a few minutes to take effect after an upgrade.

externalAccess: true puts the Tyk admin API on the public internet. The Gateway Control API under /tyk/ is served on the same port as your proxied APIs and cannot be split onto another listener, so publishing the gateway publishes key management with it and the admin secret becomes the only thing in front of it.

Redis and Sentinel

redis:
  redis:
    resources:
      cpu: 200m
      memory: 256Mi
    replicas: 2
    auth:
      password:
        enabled: true
        value: change-me-tyk-redis
    firewall:
      internal_inboundAllowType: same-gvc
    persistence:
      enabled: true
  sentinel:
    resources:
      cpu: 200m
      memory: 256Mi
    replicas: 3
    auth:
      password:
        enabled: true
        value: change-me-tyk-sentinel
    firewall:
      internal_inboundAllowType: same-gvc
    persistence:
      enabled: true

Replace both change-me-… passwords before installing. Keys under redis are passed to the bundled Redis template; see its page for the full set.

Outbound Connectivity

The gateway’s outbound firewall is closed and there is no value to open it. Every API’s target_url must point at an upstream in the same GVC, addressed by its fully qualified internal name — for example http://WORKLOAD_NAME.GVC_NAME.cpln.local:8080, where the port is the upstream workload’s container port. The upstream workload’s own internal firewall must admit the gateway. Proxying to an API on the public internet requires adding outboundAllowCIDR or outboundAllowHostname to the gateway workload yourself.

Connecting

What	Address	Notes
Public gateway	`https://CANONICAL_ENDPOINT`	Only when `externalAccess: true`. Read the endpoint from `status.canonicalEndpoint` in `cpln workload get RELEASE_NAME-tyk-api-gateway --gvc GVC_NAME -o yaml`.
Internal gateway	`http://RELEASE_NAME-tyk-api-gateway.GVC_NAME.cpln.local:8080`	Subject to `internalAccess.type`. Use your `listenPort` if you changed it.
Proxied API	`GATEWAY_ADDRESS/LISTEN_PATH`	`listen_path` comes from each API definition, for example `/app1`.
Gateway Control API	`GATEWAY_ADDRESS/tyk/keys`, `/tyk/apis`, `/tyk/reload`	Send the header `X-Tyk-Authorization` set to the payload of your admin secret.
Health check	`GATEWAY_ADDRESS/hello`	Reports gateway status and Redis connectivity.
Redis and Sentinel	`RELEASE_NAME-redis.GVC_NAME.cpln.local:6379`, `RELEASE_NAME-sentinel.GVC_NAME.cpln.local:26379`	Internal only; the gateway reaches Redis through Sentinel.

Read the admin key from its secret when you need it (it appears as payload):

cpln secret reveal ADMIN_SECRET_NAME -o yaml

To check the gateway without opening it to the internet, forward its port to your machine:

cpln port-forward RELEASE_NAME-tyk-api-gateway 8080:8080 --gvc GVC_NAME

Then, in a second terminal, call the health check and list the loaded APIs, passing the admin key in the header:

curl http://127.0.0.1:8080/hello
curl -H "X-Tyk-Authorization: ADMIN_KEY" http://127.0.0.1:8080/tyk/apis

A healthy gateway reports redis as pass in the /hello response, and /tyk/apis lists the definitions from your API secret.

Operations

Backing Up

The API definitions and policies live only in your own secrets, so keep their manifests in version control. Keys issued through the Gateway Control API, plus rate-limit and quota counters, live in the bundled Redis, whose volume sets take a daily snapshot kept for 7 days. Uninstalling the release deletes those volume sets.

Restoring a Backup

Restoring the bundled Redis from a volume-set snapshot has not been verified for this template. If you depend on keys issued through the Gateway Control API, keep a record of them outside the gateway so you can reissue them.

Updating API Definitions and Policies

Re-apply the edited manifest, then force a redeployment — a running gateway does not pick up a changed secret on its own:

cpln apply -f apis.yaml
cpln workload force-redeployment RELEASE_NAME-tyk-api-gateway --gvc GVC_NAME

Keep the secret names unchanged; the release references them by name.

Upgrading from 1.2.1 or Earlier

Version 1.3.0 is a security fix. Versions up to 1.2.1 shipped the Gateway Control API key as the values.yaml value mysecret, published the gateway to the internet by default, and hardcoded master keys on — so one guessed word yielded a key to every API.

Behavior	1.2.1 and earlier	1.3.0
Admin API key	`adminSecret` value, defaulting to `mysecret`	`adminSecretName`, naming an opaque secret you create
External access	`externalAccess`, defaulting to `true`	`externalAccess`, defaulting to `false`
Internal access	`internalAccess.type`, defaulting to `none`	`internalAccess.type`, defaulting to `same-gvc`
Master keys	Hardcoded on, no value	`allowMasterKeys`, defaulting to `false`
Redis and Sentinel passwords	`myRedisPassword` / `mySentinelPassword`	`change-me-tyk-redis` / `change-me-tyk-sentinel` placeholders

Three defaults change behavior on upgrade: the gateway stops being reachable from the internet, key-creation requests without access_rights start failing, and the internal firewall opens from none to same-gvc so every workload in the GVC can reach the gateway. Set each one explicitly if you want the old behavior. An in-place upgrade from 1.2.1 has not been verified end to end, so try it on a non-production release first.

Create the admin key secret

Use a freshly generated value — mysecret was published in a public repository, so treat any key minted under it as compromised and plan to reissue it:

printf '%s' "$(openssl rand -hex 32)" | cpln secret create-opaque --name ADMIN_SECRET_NAME --encoding plain -f -

Set adminSecretName to that name and drop adminSecret from your values; it no longer exists in the chart. Every client calling /tyk/ needs the new value.

Decide whether the gateway stays public

If clients outside Control Plane call your APIs, set externalAccess: true explicitly, knowing it also publishes /tyk/. If every caller is inside the GVC, the default same-gvc covers them.

Audit keys created without access rights

Under the old hardcoded setting such keys reach every API. List keys with GET /tyk/keys and reissue each with an access_rights entry naming only the APIs it needs.

Set the Redis and Sentinel passwords

Set redis.redis.auth.password.value and redis.sentinel.auth.password.value to values of your own; the placeholders are used verbatim otherwise.

Run the upgrade

cpln helm upgrade RELEASE_NAME oci://ghcr.io/controlplane-com/templates/tyk \
  --version 1.3.0 --gvc GVC_NAME \
  --set adminSecretName=ADMIN_SECRET_NAME

Carry over the rest of your values (API and policy secret names, passwords, access settings) with -f values.yaml or further --set flags.

Scaling and Availability

The gateway is stateless and autoscales between autoscaling.minScale and autoscaling.maxScale replicas on CPU; raise minScale to 2 or more to keep a replica serving while another restarts. Redis runs 2 replicas behind 3 Sentinels, which promote a new Redis primary if the current one fails. Set multiZone: true to spread gateway replicas across availability zones where the location supports it.

Troubleshooting

The gateway never starts after install while helm reported success

Symptom: cpln helm install succeeded, but RELEASE_NAME-tyk-api-gateway has no running containers and cpln logs returns nothing.Cause: A secret named in adminSecretName, apiSecretName or policySecretName does not exist. The defaults my-tyk-apis and my-tyk-policies count — they must exist unless set to "".Fix: Read the message naming the secret, then create it:

cpln workload get-deployments RELEASE_NAME-tyk-api-gateway --gvc GVC_NAME -o yaml

Once the secret exists the deployment recovers on its own, or run cpln workload force-redeployment RELEASE_NAME-tyk-api-gateway --gvc GVC_NAME to skip the wait.

The gateway serves Tyk Test API instead of my APIs

Symptom: The install looks healthy, but /tyk/apis lists Tyk Test API and none of your definitions.Cause: apiSecretName is "", so no definitions are mounted and the gateway falls back to the demo API baked into the upstream image.Fix: Create the API definitions secret, set apiSecretName to its name with cpln helm upgrade, and confirm with GET /tyk/apis.

Creating a key returns 400 or 500

Symptom: A key-creation request that sends "access_rights": {} is refused:

Request	Response
`POST /tyk/keys/create`	`400` — `Failed to create key, keys must have at least one Access Rights record set.`
`POST /tyk/keys/{custom-key}`	`500` — `Failed to create key, ensure security settings are correct.`

Cause: allowMasterKeys is false, so a key with no access rights is rejected. The gateway log names the reason: Master keys disallowed in configuration, key not added.Fix: Give the key an access_rights entry naming the APIs it may reach. Setting allowMasterKeys: true restores blanket keys and the exposure that comes with them. To see the log line:

cpln logs '{gvc="GVC_NAME", workload="RELEASE_NAME-tyk-api-gateway"} |= "Master keys"' --limit 50 --since 10m

An API pointing at a public upstream fails

Symptom: Requests to an API whose target_url is outside Control Plane fail, while APIs pointing at workloads in the GVC work.Cause: The gateway’s outbound firewall is closed.Fix: Point target_url at an in-GVC upstream using its fully qualified .GVC_NAME.cpln.local name, or add outboundAllowCIDR or outboundAllowHostname to the gateway workload yourself.

Another workload cannot reach the gateway

Symptom: A call from another workload to the internal gateway address does not succeed.Cause: The gateway’s internal firewall does not admit the caller. Only callers allowed by internalAccess.type can reach it.Fix: Widen internalAccess.type, or add the caller to internalAccess.workloads with type: workload-list, then allow a few minutes for the change to take effect.

An edited API definition or policy has no effect

Symptom: You re-applied the API or policy secret, but the gateway still serves the old configuration.Cause: Definitions and policies are read when the gateway starts, and a running replica does not pick up a changed secret.Fix: Force a redeployment, as in Updating API Definitions and Policies.

The workload is ready but requests fail just after start

Symptom: A newly started replica reports ready, but /hello does not yet report redis as pass and the log shows storage: Redis is either down or was not configured.Cause: The gateway declares no health probes, so ready means the container started, not that it has connected to Redis.Fix: Wait and re-check GET /hello. Expect the same short gap whenever an autoscaled replica starts.

Important Notes

Create the prerequisite secrets before installing, including apiSecretName and policySecretName unless you set them to "".
Leave externalAccess off unless you need it — enabling it also publishes the Gateway Control API under /tyk/.
Leave allowMasterKeys off — with it on, any key created without access_rights reaches every API on the gateway.
Change the Redis and Sentinel passwords — they ship as change-me-… placeholders and are used exactly as written.
Force a redeployment after changing a prerequisite secret, including after rotating the admin key — the running gateway keeps the old value until it restarts.
Your prerequisite secrets survive cpln helm uninstall — delete them yourself if you no longer need them.

External References

Tyk Gateway Documentation

Official Tyk API Gateway documentation

Gateway Configuration Options

Every gateway setting and its environment-variable name

Gateway Control API

Reference for the admin endpoints under /tyk/

API Definition Objects

Reference for the API definition JSON structure

Security Policies

Guide for configuring Tyk access policies

Tyk Template

View the source files, default values, and chart definition

Template Catalog

Templates

Overview

What Gets Created

Prerequisites

Installation

UI

CLI

Terraform

Pulumi

Configuration

Image and Port

API Definitions and Policies

Master Keys

Resources and Autoscaling

Access

Redis and Sentinel

Outbound Connectivity

Connecting

Operations

Backing Up

Restoring a Backup

Updating API Definitions and Policies

Upgrading from 1.2.1 or Earlier

Scaling and Availability

Troubleshooting

Important Notes

External References

Tyk Gateway Documentation

Gateway Configuration Options

Gateway Control API

API Definition Objects

Security Policies

Tyk Template

​Overview

​What Gets Created

​Prerequisites

​Installation

UI

CLI

Terraform

Pulumi

​Configuration

​Image and Port

​API Definitions and Policies

​Master Keys

​Resources and Autoscaling

​Access

​Redis and Sentinel

​Outbound Connectivity

​Connecting

​Operations

​Backing Up

​Restoring a Backup

​Updating API Definitions and Policies

​Upgrading from 1.2.1 or Earlier

​Scaling and Availability

​Troubleshooting

​Important Notes

​External References

Tyk Gateway Documentation

Gateway Configuration Options

Gateway Control API

API Definition Objects

Security Policies

Tyk Template

Overview

What Gets Created

Prerequisites

Installation

Configuration

Image and Port

API Definitions and Policies

Master Keys

Resources and Autoscaling

Access

Redis and Sentinel

Outbound Connectivity

Connecting

Operations

Backing Up

Restoring a Backup

Updating API Definitions and Policies

Upgrading from 1.2.1 or Earlier

Scaling and Availability

Troubleshooting

Important Notes

External References