Tyk Gateway 5.16.0

Option A: AWS Marketplace console

• Open the SecureAnyCloud Hardened WireGuard VPN & VPN, Proxy and Remote Access AMIs listing on AWS Marketplace, choose View purchase options, and then choose Subscribe. One subscription covers every version in the listing.
• Once the subscription is active, choose Launch your software.
• Choose One-click launch from AWS Marketplace, or choose Launch from EC2 Console for the full launch wizard. In Version, choose Tyk Gateway 5.16.0 on Ubuntu 24.04, and then choose your Region.
• Pick an instance type (m5.large is recommended; the software charge is $0.04 per vCPU per hour) and your key pair.
• In the security group, allow SSH (22) from your own IP address. Allow HTTPS (443) and HTTP (80, which only redirects to HTTPS) from the clients that will call your APIs.
• Choose your VPC and subnet, leave the metadata defaults (the image already requires IMDSv2), and then choose Launch.

Option B: AWS CLI

Run the commands on your own workstation. Replace the AMI ID with the one shown for your Region on the Marketplace launch page. Replace the VPC, subnet, key pair and CIDR ranges with your own values:

SG=$(aws ec2 create-security-group --group-name tyk-gateway \
  --description "Tyk Gateway" --vpc-id vpc-0123456789abcdef0 \
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 22 --cidr <your-mgmt-cidr>
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 443 --cidr <your-client-cidr>
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 80 --cidr <your-client-cidr>
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids "$SG" \
  --subnet-id subnet-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=tyk-gateway}]'

You do not need --metadata-options, because the AMI already requires IMDSv2.

Connect as ubuntu with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>

First boot finishes within a minute of launch. It does the following:

• Generates this instance's Gateway API secret, node secret and Valkey password.
• Writes Tyk's configuration and Valkey's access list, which stores only a SHA-256 hash of the password.
• Creates the TLS certificate for the instance's public DNS name.
• Starts Valkey, Tyk Gateway and nginx.
• Checks that the Gateway API refuses requests without the secret.

The details are in /root/tyk-gateway-credentials.txt, which only root can read. This command prints everything except the three secret lines:

sudo grep -vE '^(TYK_SECRET|TYK_NODE_SECRET|VALKEY_PASSWORD)=' /root/tyk-gateway-credentials.txt

# Tyk Gateway 5.16.0 (open source, MPL-2.0) - generated on first boot by tyk-gateway-firstboot.service.
# Every value below is unique to this instance; nothing was baked into the image. Keep this file private.
#
# Your APIs: https://ec2-54-172-240-122.compute-1.amazonaws.com/<listen-path>/ (:80 redirects here; open 443 in the security group)
# Health: https://ec2-54-172-240-122.compute-1.amazonaws.com/hello
# Gateway API: http://127.0.0.1:9696/tyk/... ON THIS INSTANCE ONLY, header x-tyk-authorization: <TYK_SECRET> TYK_GATEWAY_API=http://127.0.0.1:9696 VALKEY_HOST=127.0.0.1 VALKEY_PORT=6379
# Self-test:
sudo tyk-gateway-selftest Another host name:
sudo tyk-gateway-set-host <name>
# Guide: https://secureanycloud.com/stacks/tyk-gateway-5-16-0/ TYK_HOST=ec2-54-172-240-122.compute-1.amazonaws.com TYK_URL=https://ec2-54-172-240-122.compute-1.amazonaws.com/ TLS_CERT_SHA256=08:0C:23:9A:33:7C:3F:7A:99:B1:FA:A3:00:E9:10:F9:04:3C:45:EA:08:65:55:EA:40:63:A9:AB:75:13:81:5A

TYK_HOST is your instance's public DNS name, or its IP address when the subnet gives it no public name. TLS_CERT_SHA256 is the fingerprint of the certificate that nginx serves. Compare it with the fingerprint your client shows the first time it connects.

To read the secrets when you need them, run sudo cat /root/tyk-gateway-credentials.txt.

systemctl is-active valkey tyk-gateway nginx tyk-gateway-firstboot ps -o user=,comm= -C tyk,valkey-server,nginx | sort -u

active active active active root nginx tyk tyk valkey valkey-server www-data nginx

Tyk Gateway runs as tyk and Valkey runs as valkey. Only the nginx master process runs as root, because it reads the TLS key and opens ports 80 and 443. Check the listening ports:

sudo ss -Hltn | awk '{print $4}' | sort

0.0.0.0:22 0.0.0.0:443 0.0.0.0:80 127.0.0.1:6379 127.0.0.1:8080 127.0.0.1:9696 127.0.0.53%lo:53 127.0.0.54:53 [::]:22 [::]:443 [::]:80

Only SSH and nginx (80, 443) listen on the network. Valkey (6379), Tyk's data plane (8080) and the Gateway API (9696) listen on 127.0.0.1 only.

Tyk opens 8080 only while at least one API is loaded. Once Tyk has proxied a request, it also keeps an "all hosts are down" helper on one random 127.0.0.1 port. The two :53 sockets are Ubuntu's local DNS resolver.

The image includes a self-test that exercises the whole path without printing a secret. It creates a temporary API, sends a request through nginx and Tyk Gateway, and deletes the API again. Run it:

sudo tyk-gateway-selftest

SELFTEST_OK valkey=auth-required tyk=tyk gateway-api=403/403/200 https-hello=200 tyk-path-via-nginx=404 proxied-api=200 imds-from-tyk=000

You configure Tyk Gateway through its Gateway API on http://127.0.0.1:9696/tyk/, with the secret in the x-tyk-authorization header. Put the header in a root-only file on the instance's temporary file system, which is removed at reboot. The secret then never appears on a command line or in your shell history:

sudo sh -c 'umask 077; printf "x-tyk-authorization: %s\n" "$(sed -n "s/^TYK_SECRET=//p" /root/tyk-gateway-credentials.txt)" > /run/tyk-gateway-api.header'
sudo curl -s -H @/run/tyk-gateway-api.header http://127.0.0.1:9696/tyk/apis; echo

[]

The gateway starts with no APIs. Without the secret, the Gateway API refuses the request:

curl -s http://127.0.0.1:9696/tyk/apis; echo

{"status":"error","message":"Attempted administrative access with invalid or missing key!"}

The following commands create a keyless API that publishes https://ip-ranges.amazonaws.com/ under the listen path /aws-ip-ranges/, and then hot-reload the gateway:

sudo curl -s -H @/run/tyk-gateway-api.header -H 'Content-Type: application/json' \
  -d '{"name":"aws-ip-ranges","api_id":"aws-ip-ranges","org_id":"default","use_keyless":true,"active":true, "version_data":{"not_versioned":true,"versions":{"Default":{"name":"Default"}}}, "proxy":{"listen_path":"/aws-ip-ranges/","target_url":"https://ip-ranges.amazonaws.com/","strip_listen_path":true}}' \
  http://127.0.0.1:9696/tyk/apis; echo
sudo curl -s -H @/run/tyk-gateway-api.header http://127.0.0.1:9696/tyk/reload/group; echo

{"key":"aws-ip-ranges","status":"ok","action":"added"} {"status":"ok","message":""}

Call the API through nginx and Tyk. On the instance itself, --resolve points the instance's host name at 127.0.0.1. From your workstation, call https://<TYK_HOST>/aws-ip-ranges/ip-ranges.json directly, after you open port 443 to your address:

H=$(sudo sed -n 's/^TYK_HOST=//p' /root/tyk-gateway-credentials.txt) sleep 2 curl -s -o /dev/null -w '%{http_code} %{content_type}\n' --cacert /etc/nginx/sac/tls/tyk-gateway.crt \
  --resolve "$H:443:127.0.0.1" "https://$H/aws-ip-ranges/ip-ranges.json"

200 application/json

Port 80 only redirects to the configured host on HTTPS. Confirm the redirect:

H=$(sudo sed -n 's/^TYK_HOST=//p' /root/tyk-gateway-credentials.txt)
curl -s -o /dev/null -D - --resolve "$H:80:127.0.0.1" "http://$H/aws-ip-ranges/ip-ranges.json" | tr -d '\r' \
  | awk -v want="https://$H/aws-ip-ranges/ip-ranges.json" 'NR==1{print $2} tolower($1)=="location:"{print ($2==want ? "Location: https, same host and path" : "Location: unexpected")}'

301 Location: https, same host and path

To protect an API with keys, set "use_keyless": false and an authentication method in its definition, and then create keys with POST /tyk/keys/create. Tyk's documentation covers keys, policies, rate limits and the other API definition options.

API definitions that you create through the Gateway API are stored in /opt/tyk-gateway/apps/. Keys and sessions are stored in Valkey.

nginx never forwards /tyk/, and the Gateway API listens on loopback only. Verify both:

H=$(sudo sed -n 's/^TYK_HOST=//p' /root/tyk-gateway-credentials.txt)
curl -s -o /dev/null -w '%{http_code}\n' --cacert /etc/nginx/sac/tls/tyk-gateway.crt --resolve "$H:443:127.0.0.1" "https://$H/tyk/apis"
curl -s -m 5 "http://$(hostname -I | awk '{print $1}'):9696/hello" || echo "connection refused on the private address"

404 connection refused on the private address

Requests for any host name that is not this instance's configured name or address get no answer, so nobody can reach the gateway through someone else's DNS name.

An API definition can point Tyk Gateway at any upstream, so the image blocks the instance metadata service (169.254.169.254, its IPv6 address and 168.63.129.16) for the Tyk Gateway, Valkey and nginx services at the system level.

The following commands publish an API whose upstream is the metadata service and then call it. Tyk waits 15 seconds for an answer that never comes:

sudo curl -s -H @/run/tyk-gateway-api.header -H 'Content-Type: application/json' \
  -d '{"name":"imds-test","api_id":"imds-test","org_id":"default","use_keyless":true,"active":true, "version_data":{"not_versioned":true,"versions":{"Default":{"name":"Default"}}}, "proxy":{"listen_path":"/imds-test/","target_url":"http://169.254.169.254/latest/meta-data/","strip_listen_path":true}}' \
  http://127.0.0.1:9696/tyk/apis; echo
sudo curl -s -H @/run/tyk-gateway-api.header http://127.0.0.1:9696/tyk/reload/group; echo
H=$(sudo sed -n 's/^TYK_HOST=//p' /root/tyk-gateway-credentials.txt) sleep 2 curl -s -w '\nHTTP %{http_code}\n' --cacert /etc/nginx/sac/tls/tyk-gateway.crt --resolve "$H:443:127.0.0.1" "https://$H/imds-test/"

{"key":"imds-test","status":"ok","action":"added"} {"status":"ok","message":""} { "error": "There was a problem proxying the request" } HTTP 500

The block covers every way Tyk can send a request: upstream URLs, load-balancing target lists, URL rewrites, service discovery, JWKS and introspection fetches, and webhooks.

Remove the test API, the example API and the header file:

for a in imds-test aws-ip-ranges; do
sudo curl -s -X DELETE -H @/run/tyk-gateway-api.header "http://127.0.0.1:9696/tyk/apis/$a"; echo; done
sudo curl -s -H @/run/tyk-gateway-api.header http://127.0.0.1:9696/tyk/reload/group; echo
sudo shred -u /run/tyk-gateway-api.header

{"key":"imds-test","status":"ok","action":"deleted"} {"key":"aws-ip-ranges","status":"ok","action":"deleted"} {"status":"ok","message":""}

Try to connect to Valkey without the password:

valkey-cli -h 127.0.0.1 PING

NOAUTH Authentication required.

Tyk Gateway already has the password in /opt/tyk-gateway/tyk.conf. For your own maintenance, sudo cat /root/tyk-gateway-credentials.txt shows VALKEY_PASSWORD. Use it with valkey-cli --askpass so that it never lands on a command line.

Point a DNS name at the instance. An Elastic IP is recommended so that the address survives a stop and start. Then run:

sudo tyk-gateway-set-host api.example.com

The command creates a new key and certificate for the name and makes it the name that port 80 redirects to. It also updates TYK_HOST, TYK_URL and TLS_CERT_SHA256 in the credentials file. The instance's public and private IP addresses stay accepted.

For production, replace /etc/nginx/sac/tls/tyk-gateway.crt and .key with a certificate from your certificate authority and reload nginx (sudo systemctl reload nginx).

List browser applications on other origins that open WebSockets through the gateway in /etc/nginx/sac/tyk-gateway-origins.map, with one "https://app.example.com" 1; line each. Non-browser clients are not affected.

The image ships Tyk's packagecloud repository with its signing key pinned but disabled, so nothing changes the gateway unexpectedly.

To upgrade, set Enabled: yes in /etc/apt/sources.list.d/tyk-gateway.sources, and then run sudo apt-get update && sudo apt-get install --only-upgrade tyk-gateway. Read Tyk's release notes for configuration changes first. Ubuntu security updates continue to install automatically.