Documentation Index
Fetch the complete documentation index at: https://tyk.io/docs/llms.txt
Use this file to discover all available pages before exploring further.
Overview
In some environments, direct access to public container registries and package repositories is restricted. This guide provides instructions for deploying Tyk in such air-gapped or network-restricted environments. There are two main deployment scenarios covered:- Kubernetes (Helm) — Mirroring container images and packaging Helm charts for offline installation.
- Bare Metal / VMs (Linux packages) — Creating a local mirror of Tyk’s PackageCloud repositories for
aptoryumbased installations.
Kubernetes: Image Mirroring and Helm Chart Packaging
Step 1: Identify Required Container Images
Usehelm template on an internet-connected machine to extract all container images referenced by the Tyk chart you plan to deploy.
First, add the Tyk Helm repository:
tyk-stack (Tyk Self-Managed). Replace it with the chart that matches your deployment (e.g. tyk-oss, tyk-data-plane, tyk-control-plane):
Enable optional components with
--set flags so their images are included in the output. For example, add --set global.components.devPortal=true for the Developer Portal or --set global.components.operator=true for the Tyk Operator.Step 2: Pull, Re-tag, and Push Images to Your Private Registry
On an internet-connected machine, pull each image, re-tag it for your private registry, and push it:docker save and docker load to transfer images via archive files if your air-gapped environment does not have a private registry:
Step 3: Package Helm Charts for Offline Use
On the internet-connected machine, pull and package the chart as a.tgz archive:
.tgz file to the air-gapped environment. You can then install directly from the archive:
Step 4: Configure Helm Charts to Use the Private Registry
Setglobal.imageRegistry in your values.yaml to point all image pulls at your private registry:
values.yaml:
Alternative: Container Runtime (CRI) Mirror Configuration
Instead of changing Helm values, you can configure your container runtime (Docker, containerd, CRI-O) to transparently redirect pull requests from public registries to your private registry. This is done at the Kubernetes node level and avoids any changes to your Helm configuration. Refer to your container runtime’s documentation for mirror configuration instructions.Bare Metal / VMs: Linux Package Mirror
For installations on bare metal servers or VMs that use Linux packages (deb or rpm), you can create a local mirror of the Tyk repositories hosted on PackageCloud.
Required Tyk Packages
A standard Tyk Self-Managed deployment requires these packages:| Package | Description |
|---|---|
tyk-gateway | API Gateway |
tyk-dashboard | Management Dashboard |
tyk-pump | Analytics Pump |
| Package | Description |
|---|---|
tyk-identity-broker | SSO / Identity Broker |
tyk-sync | Git-based API definition sync |
tyk-mdcb | Multi Data Center Bridge (from tyk-mdcb-stable repo) |
Option A: Mirroring Repositories
Use a tool likedebmirror (Debian/Ubuntu) or reposync (RHEL/CentOS) to create a local mirror of the Tyk repositories from PackageCloud. This allows you to maintain an up-to-date mirror that can be easily accessed by multiple machines in the air-gapped environment.
Option B: Direct Package Download
If mirroring the full repository is not practical, you can download individual.deb or .rpm packages directly from PackageCloud and transfer them manually.
- Debian / Ubuntu
- RHEL / CentOS