Tyk Gateway Open Source API Gateway on AWS User Guide

Overview

This guide covers the deployment and configuration of Tyk Gateway on AWS using cloudimg AWS Marketplace images. Tyk Gateway is a fast, cloud native, open source API gateway written in Go. It sits in front of your services and handles authentication, authorization, rate limiting, quotas, request and response transformation, API versioning and analytics, all driven by declarative API definitions. This image ships the open source Gateway on its own, in file based mode with a local Redis datastore, so you get a complete standalone gateway with no external dependencies, no Dashboard and no commercial components.

The image installs the Gateway from the official, unmodified open source Tyk package, run under systemd as tyk-gateway.service. The gateway binds to loopback only and serves the data plane, the unauthenticated /hello health endpoint and the secret gated control API (/tyk/*) all on one local port (127.0.0.1:8080). A local Redis instance, also bound to loopback, is the required datastore for keys, analytics and rate limiting. An nginx front end publishes the data plane and the public health endpoint on port 80, and explicitly refuses the control API path so the control plane is never reachable from the internet.

Secure by default - no known secret. The control API secret is what lets you create and rotate API definitions and keys, so a shared or baked in secret would let anyone drive your gateway. This image avoids that: on the first boot of every instance a one shot service generates a unique 64 character control API secret for this instance alone, rewrites the gateway configuration with strict permissions, resolves this instance's public URL, records the secret and URL in a root only file, and only then starts the gateway. The control API and Redis are bound to loopback, and the public port 80 returns a forbidden response for the control API path.

What is included:

• Tyk Gateway (version 5.14.0) installed from the official open source package, run under systemd as tyk-gateway.service

• A local Redis datastore (redis-server.service) bound to 127.0.0.1:6379, the required store for keys, quotas, rate limit counters and analytics

• An nginx front end publishing the data plane and the public /hello health endpoint on port 80, and returning 403 for the control API path /tyk/

• The control API (/tyk/*) bound to loopback 127.0.0.1:8080, gated by a per instance secret via the x-tyk-authorization header

• A unique per instance control API secret generated on first boot, written with the instance public URL to /root/tyk-gateway-credentials.txt (root only)

Prerequisites

• An AWS account subscribed to the Tyk Gateway listing on AWS Marketplace

• An EC2 key pair for SSH access, and a VPC + subnet in your target region

• A security group allowing TCP 22 (administration) and TCP 80 (API traffic to the data plane and the health endpoint)

Recommended instance type: m5.large (2 vCPU, 8 GB RAM) is a comfortable starting point for a production gateway. Tyk Gateway is a lightweight Go daemon; scale the instance type up for very high request throughput.

Connecting to your instance

Connect over SSH as the default login user for the operating system variant you launched:

Replace <public-ip> with your instance's public IPv4 address (or DNS name) from the EC2 console, and your-key.pem with the private key for the key pair you launched with.

First boot and your per instance secret

On first boot the image generates a unique control API secret for this instance and records it, together with the instance public URL, in a root only credentials file. Read it with:

sudo cat /root/tyk-gateway-credentials.txt

This file contains:

• TYK_SECRET - the per instance control API secret. Send it in the x-tyk-authorization header on every control API call. Keep this file secret; it is 0600 root:root.

• TYK_URL - this instance's public base URL (for example http://<public-ip>/), where the data plane and the /hello health endpoint are reachable.

There is no default or shared secret. Two instances launched from this image get different secrets.

Checking gateway health

The gateway exposes an unauthenticated /hello liveness endpoint that also reports the Redis datastore health. It is reachable on the public port 80 and on the loopback data plane:

curl http://<public-ip>/hello

{"status":"pass","version":"5.14.0","description":"Tyk GW","details":{"redis":{"status":"pass","componentType":"datastore","time":"2026-07-24T04:23:31Z"}}}

A status of pass confirms the gateway is serving and Redis is connected.

The control API is gated and loopback only

The control API (/tyk/*) is how you create, list and remove API definitions and keys. It is bound to loopback 127.0.0.1:8080 and requires the per instance secret. A request with no secret, or via the public port 80, is rejected:

# read the per instance secret into a shell variable (never echo it)
SECRET=$(sudo awk -F= '/^TYK_SECRET=/{print $2}' /root/tyk-gateway-credentials.txt)

# no secret -> rejected
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/tyk/apis
# correct secret -> 200
curl -s -o /dev/null -w '%{http_code}\n' -H "x-tyk-authorization: $SECRET" http://127.0.0.1:8080/tyk/apis
# via the public :80 -> refused by nginx
curl -s -o /dev/null -w '%{http_code}\n' http://<public-ip>/tyk/apis

403
200
403

Only a request on the loopback interface carrying the correct per instance secret reaches the control API. The public port 80 serves only the data plane and the health endpoint.

Defining an API and proxying a request through the gateway

Create a declarative API definition through the control API, then hot reload the gateway. This example proxies requests under /httpbin/ to a public upstream:

SECRET=$(sudo awk -F= '/^TYK_SECRET=/{print $2}' /root/tyk-gateway-credentials.txt)

curl -s -H "x-tyk-authorization: $SECRET" -H 'Content-Type: application/json' -X POST -d '{
  "name":"httpbin","api_id":"httpbin","org_id":"cloudimg","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

{"key":"httpbin","status":"ok","action":"added"}
{"status":"ok","message":""}

Now send a request through the public data plane on port 80. The gateway proxies it to the upstream and returns the response:

curl http://<public-ip>/httpbin/get

{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Accept-Encoding": "gzip",
    "Host": "httpbin.org",
    "User-Agent": "curl/8.5.0"
  },
  "origin": "127.0.0.1, 127.0.0.1, 34.203.215.132",
  "url": "http://httpbin.org/get"
}

The request entered the gateway on port 80, was matched to the /httpbin/ listen path and forwarded to the upstream, proving traffic proxies through the gateway. From here you can layer authentication, rate limiting and quotas onto the API definition, or point target_url at your own service.

Security model and hardening

• No known credential. The control API secret is generated uniquely per instance on first boot. There is no default or shared secret baked into the image.

• Loopback control plane. The gateway (data plane, /hello and the control API) binds to 127.0.0.1:8080, and Redis to 127.0.0.1:6379. Neither is reachable from the network directly.

• nginx boundary. nginx on port 80 publishes only the data plane and the /hello health endpoint, and returns 403 for /tyk/, so the control plane is never internet reachable.

• Minimal exposure. The recommended security group opens only TCP 22 (SSH, key only) and TCP 80 (API traffic). Restrict port 80 to the clients that call your APIs, and administer over SSH with your EC2 key pair.

• Terminate TLS at the edge. For production, front the gateway with TLS - terminate HTTPS in nginx on this instance, or place an Application Load Balancer or CloudFront in front of port 80.

Managing the services

The gateway, its datastore and the front end run under systemd:

systemctl status tyk-gateway
systemctl status redis-server
systemctl status nginx

# after editing /opt/tyk-gateway/tyk.conf
sudo systemctl restart tyk-gateway

API definitions are stored as JSON files under /opt/tyk-gateway/apps/. You can manage them through the control API (recommended) or by editing files and reloading the gateway with a call to /tyk/reload/group.

Support

cloudimg provides 24/7 technical support for this Tyk Gateway image by email (support@cloudimg.co.uk) and live chat, with a one hour average response time for critical issues. We help with authoring API definitions, authentication and rate limit policies, nginx and TLS front end configuration, connecting the gateway to your services, security group rules, health checks, and Tyk Gateway version upgrades.

Tyk Gateway is open source software distributed under the MPL-2.0 license. cloudimg is not affiliated with or endorsed by Tyk Technologies; the Tyk name is used only to identify the open source software shipped in this image.