Tyk Gateway

Sign in to the Azure portal, choose Create a resource, search the Marketplace for Tyk Gateway by SecureAnyCloud, and select Create.

On Basics, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80). Then select Review + create and Create.

Run these commands to create the network, accept the Marketplace terms and create the VM:

RG="tyk-prod"; LOCATION="eastus"; VM_NAME="tyk-01" IMAGE_URN="sac1647283583153:tyk-gateway-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name tyk-vnet --address-prefix 10.100.0.0/16 --subnet-name tyk-subnet --subnet-prefix 10.100.1.0/24 az network nsg create -g "$RG" --name tyk-nsg az network nsg rule create -g "$RG" --nsg-name tyk-nsg --name allow-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name tyk-nsg --name allow-http --priority 110 \
  --destination-port-ranges 80 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:tyk-gateway-ubuntu-24-04:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name tyk-vnet --subnet tyk-subnet --nsg tyk-nsg --public-ip-sku Standard

SSH to the VM as azureuser. Confirm that the gateway, its Redis datastore and nginx are running, and check the listeners:

sudo /opt/tyk-gateway/tyk --version systemctl is-active redis-server tyk-gateway nginx
sudo ss -tlnp | grep -E ':80 |:8080|:6379' | awk '{print $1" "$4}' | sort -u

The version prints 5.14.0, and all three services report active. The listeners show nginx on 0.0.0.0:80, the Tyk gateway on 127.0.0.1:8080 and Redis on 127.0.0.1:6379. The gateway and Redis are bound to the loopback interface, so the only public entry point is nginx on port 80.

The gateway exposes a public, unauthenticated /hello liveness endpoint that reports the gateway version and the health of its Redis datastore. nginx serves it on port 80, so you can use it for a load balancer health probe:

curl -s http://localhost/hello

This returns a JSON document with "status":"pass", the gateway version, and a redis component also reporting "status":"pass". No authentication is required for this endpoint.

A secret generated uniquely on the first boot of each VM protects the gateway control API. First boot writes it, along with the resolved public URL, to a 0600 root:root credentials file. View the file with the commands below. The guide masks the secret, but the real value is on your VM:

sudo stat -c '%A %U:%G %n' /root/tyk-gateway-credentials.txt
sudo grep -E '^TYK_SECRET=|^TYK_URL=' /root/tyk-gateway-credentials.txt \
  | sed -r 's/(TYK_SECRET)=.*/\1=<PER-VM-64-HEX-SECRET>/'

The file is -rw------- root:root. The TYK_SECRET is a 64 hex character value unique to this VM, created by openssl rand -hex 32 on first boot before the gateway started. There is no default or known secret in the image. The same secret gates every control API call.

The control API lives at /tyk/* on the loopback interface (127.0.0.1:8080) and is gated by the secret. nginx returns 403 for /tyk/ on the public port 80, so the control plane is never reachable from the internet.

Confirm that a missing or wrong secret is rejected with 403, while the per-instance secret authenticates:

SECRET=$(sudo grep '^TYK_SECRET=' /root/tyk-gateway-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w 'control API (no secret): %{http_code}\n' http://127.0.0.1:8080/tyk/apis
curl -s -o /dev/null -w 'control API (wrong secret): %{http_code}\n' -H 'x-tyk-authorization: wrong' http://127.0.0.1:8080/tyk/apis
curl -s -o /dev/null -w 'control API (real secret): %{http_code}\n' -H "x-tyk-authorization: $SECRET" http://127.0.0.1:8080/tyk/apis
curl -s -o /dev/null -w 'control API via public :80: %{http_code}\n' http://localhost/tyk/apis

The calls with no secret and a wrong secret are rejected with 403. The call with the real per-instance secret returns 200, and the control API path on the public port 80 returns 403.

This is the whole security model. The health probe is open, the data plane proxies your APIs, and the control plane is on loopback, gated by the per-instance secret, and never exposed publicly.

You manage the gateway by posting API definitions to the control API and hot reloading. Create a simple keyless API that proxies /httpbin/ to the public httpbin.org service, reload the gateway, then send a request through the data plane to see it proxied to the upstream:

SECRET=$(sudo grep '^TYK_SECRET=' /root/tyk-gateway-credentials.txt | cut -d= -f2-)
curl -s -H "x-tyk-authorization: $SECRET" -H 'Content-Type: application/json' -X POST \
  -d '{"name":"httpbin","api_id":"httpbin","org_id":"sac","use_keyless":true, "version_data":{"not_versioned":true,"versions":{"Default":{"name":"Default"}}}, "proxy":{"listen_path":"/httpbin/","target_url":"http://httpbin.org","strip_listen_path":true}, "active":true}' \
  http://127.0.0.1:8080/tyk/apis
curl -s -H "x-tyk-authorization: $SECRET" http://127.0.0.1:8080/tyk/reload/group >/dev/null sleep 2
curl -s http://localhost/httpbin/get | head -c 200 echo

The POST /tyk/apis returns {"key":"httpbin","status":"ok","action":"added"}, the reload returns 200, and the request to http://localhost/httpbin/get is proxied through the gateway to httpbin.org and returns the upstream JSON response. You have now published an API through Tyk. Replace target_url with your own upstream service and listen_path with the route you want to expose.

Most real APIs are not keyless. Set use_keyless to false with an auth token configuration, then mint a key over the control API. These commands create a protected API on /secure/, then create a key scoped to it:

SECRET=$(sudo grep '^TYK_SECRET=' /root/tyk-gateway-credentials.txt | cut -d= -f2-)
curl -s -H "x-tyk-authorization: $SECRET" -H 'Content-Type: application/json' -X POST \
  -d '{"name":"secure-api","api_id":"secure","org_id":"sac","use_keyless":false, "auth":{"auth_header_name":"Authorization"}, "version_data":{"not_versioned":true,"versions":{"Default":{"name":"Default"}}}, "proxy":{"listen_path":"/secure/","target_url":"http://httpbin.org","strip_listen_path":true}, "active":true}' \
  http://127.0.0.1:8080/tyk/apis >/dev/null curl -s -H "x-tyk-authorization: $SECRET" http://127.0.0.1:8080/tyk/reload/group >/dev/null sleep 2 curl -s -o /dev/null -w 'secure API (no key): %{http_code}\n' http://localhost/secure/get
KEY=$(curl -s -H "x-tyk-authorization: $SECRET" -H 'Content-Type: application/json' -X POST \
  -d '{"allowance":1000,"rate":100,"per":60,"quota_max":-1, "access_rights":{"secure":{"api_id":"secure","api_name":"secure-api","versions":["Default"]}}}' \
  http://127.0.0.1:8080/tyk/keys | python3 -c 'import sys,json;print(json.load(sys.stdin)["key_id"])')
curl -s -o /dev/null -w 'secure API (with key): %{http_code}\n' -H "Authorization: $KEY" http://localhost/secure/get

The unauthenticated call to /secure/get is rejected with 401, and the same call with the minted key returns 200. Keys carry their own rate limit (rate/per) and quota, which the gateway enforces using its Redis datastore.

From anywhere that can reach the VM on port 80, call your published APIs at the VM public IP. The /hello health check and any keyless API need no credentials:

curl http://<vm-ip>/hello
curl http://<vm-ip>/httpbin/get

To manage the gateway (add or change API definitions) from outside the VM, SSH in and use the control API on 127.0.0.1:8080 with the per-instance secret, or front the gateway with your own management tooling. The control API is intentionally not exposed on the public port.

The image serves the API over plain HTTP on port 80, which suits a load balancer or private network. For production, terminate TLS in front of Tyk so credentials and payloads travel encrypted:

• Front the VM with Azure Application Gateway, a load balancer with a managed certificate, or a CDN, and forward to nginx on port 80.
• Or install your own certificate: add a TLS server block that references your certificate and key to /etc/nginx/sites-available/tyk-gateway, open 443/tcp on the NSG, then run sudo systemctl reload nginx.
• Point a DNS name you control at the VM public IP and use that name (and https://) for your API consumers.

Component Version / Detail

API gateway Tyk Gateway v5.14.0 (open source, MPL-2.0, Gateway edition)

API front nginx on :80 reverse proxying to 127.0.0.1:8080

Datastore local Redis 7 (loopback 127.0.0.1:6379, no host port)

Control API /tyk/* on loopback 127.0.0.1:8080, gated by the per instance secret; 403 on public :80

Health endpoint /hello (public, no auth) reporting gateway + Redis health

Control API secret per instance, generated first boot into /root/tyk-gateway-credentials.txt

Mode OSS file based (use_db_app_configs false), no Dashboard