Skip to main content

​
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 apt or yum based installations.

​
Kubernetes: Image Mirroring and Helm Chart Packaging

​
Step 1: Identify Required Container Images

Use helm 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:
Then render the chart templates and extract the image references. The example below uses 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.
Typical output includes images such as:

​
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:
Alternatively, you can use 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:
Transfer the .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

Set global.imageRegistry in your values.yaml to point all image pulls at your private registry:
This prefix is prepended to every image repository defined in the chart, so all components (Gateway, Dashboard, Pump, bootstrap jobs, etc.) will pull from your private registry. If your private registry requires authentication, create an image pull secret and reference it:
Then in your 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: Optional packages depending on your deployment:

​
Option A: Mirroring Repositories

Use a tool like debmirror (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.