Installation Options for Tyk Self-Managed

Explore the various installation options for Tyk Self-Managed, including Docker, Kubernetes, Ansible, and more.

Install on AWS Marketplace

Tyk offers a flexible and powerful API management solution through Tyk Cloud on the AWS Marketplace. Tyk Cloud is an end-to-end managed API platform where both the control plane and gateways are installed on AWS for a seamless, fully cloud-hosted experience.

For those who need more deployment flexibility, Tyk Cloud also supports a Hybrid Gateway option. In this setup, the control plane remains hosted and managed by Tyk on AWS, while the gateways can be deployed on your preferred cloud provider or on-premises environment—allowing you to meet data locality and compliance needs without sacrificing control.

Available AWS Deployment Regions

You can deploy Tyk Cloud in the following AWS regions:

• Singapore: aws-ap-southeast-1
• Frankfurt, Germany: aws-eu-central-1
• London, UK: aws-eu-west-2
• N. Virginia, USA: aws-us-east-1
• Oregon, USA: aws-us-west-2
• Australia: aws-ap-southeast-2

Getting started with Tyk Cloud via the AWS Marketplace is quick and easy. Sign up today to access Tyk’s comprehensive API management tools designed to scale with your needs.

Install Tyk on AWS EC2

1. Spin up an EC2 instance, AWS Linux2 preferably, T2.Medium is fine

   • add a public IP
   • open up SG access to:
     • 3000 for the Tyk Dashboard
     • 8080 for the Tyk Gateway
     • 22 TCP for SSH

2. SSH into the instance ssh -i mykey.pem ec2-user@public-ec2-ip

3. Install Git, Docker, & Docker Compose Feel free to copy paste these

sudo yum update -y
sudo yum install git -y
sudo yum install -y docker
sudo service docker start
sudo usermod -aG docker ec2-user
sudo su
sudo curl -L "https://github.com/docker/compose/releases/download/1.25.5/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
docker ps

4. Clone the Tyk Pro Docker repo

git clone https://github.com/TykTechnologies/tyk-pro-docker-demo
cd tyk-pro-docker-demo/

5. Add the license key to confs/tyk_analytics.conf into the license_key variable using “vi” or “nano”, etc

This is the most common place to have problems.

Look for extra spaces between quotes ("") and the license key. It will not work if there are any.

Inside tyk_analytics.conf, license_key should look something like this, with a real license however:

"license_key": "eyJhbGciOiJSUzI1NiIsInR5cCI...WQ",

6. Run the containers via docker-compose

docker-compose up -d

7. Visit

http://<public-ec2-ip>:3000

and fill out the Bootstrap form! If you see any page besides the Bootstrap page, you have pasted the license key incorrectly

Enable SSL for the Gateway & Dashboard

1. Add the following to confs/tyk.conf

"policies.policy_connection_string": "https://tyk-dashboard:3000"
"db_app_conf_options.connection_string": "https://tyk-dashboard:3000"
"http_server_options": {
  "use_ssl": true,
  "certificates": [
    {
      "domain_name": "*.yoursite.com",
      "cert_file": "./new.cert.cert",
      "key_file": "./new.cert.key"
    }
  ],
  "ssl_insecure_skip_verify": true   ## YOU ONLY NEED THIS IF YOU ARE USING SELF SIGNED CERTS
}

2. Add the following to confs/tyk_analytics.conf

"tyk_api_config.Host": "https://tyk-gateway"
"http_server_options": {
  "use_ssl": true,
  "certificates": [
    {
      "domain_name": "*.yoursite.com",
      "cert_file": "./new.cert.cert",
      "key_file": "./new.cert.key"
    }
  ]
}

3. Generate self-signed Certs: (Or bring your own CA signed)

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

4. Mount your certs to containers through docker-compose.yml

tyk-dashboard:
    ...
    volumes: 
    - ./cert.pem:/opt/tyk-dashboard/new.cert.cert
    - ./key.pem:/opt/tyk-dashboard/new.cert.key
tyk-gateway:
    ...
    volumes: 
    - ./cert.pem:/opt/tyk-gateway/new.cert.cert
    - ./key.pem:/opt/tyk-gateway/new.cert.key

5. Restart your containers with the mounted files

docker-compose up -d tyk-dashboard tyk-gateway

6. Download the bootstrap script onto EC2 machine

wget https://raw.githubusercontent.com/sedkis/tyk/master/scripts/bootstrap-ssl.sh

7. Apply execute permissions to file:

chmod +x bootstrap.sh

8. Run the bootstrap script

./bootstrap.sh localhost

9. Done! use the generated user and password to log into The Tyk Dashboard

Install with Ansible

Requirements

Ansible is required to run the following commands.

Getting Started

1. clone the tyk-ansible repositry

   $ git clone https://github.com/TykTechnologies/tyk-ansible
   

2. cd into the directory

   $ cd tyk-ansible
   

3. Run initialisation script to initialise environment

   $ sh scripts/init.sh
   

4. Modify hosts.yml file to update ssh variables to your server(s). You can learn more about the hosts file here

5. Run ansible-playbook to install the following:

   • Redis
   • MongoDB or PostgreSQL
   • Tyk Dashboard
   • Tyk Gateway
   • Tyk Pump
   $ ansible-playbook playbook.yaml -t tyk-pro -t redis -t `mongodb` or `pgsql`
   

   You can choose to not install Redis, MongoDB or PostgreSQL by removing the -t redis or -t mongodb or -t pgsql However Redis and MongoDB or PostgreSQL are a requirement and need to be installed for the Tyk Pro installation to run.

   For a production environment, we recommend that the Gateway, Dashboard and Pump are installed on separate machines. If installing multiple Gateways, you should install each on a separate machine. See Planning for Production For more details.

Supported Distributions

Distribution	Version	Supported
Amazon Linux	2	✅
CentOS	8	✅
CentOS	7	✅
Debian	10	✅
Debian	9	✅
RHEL	9	✅
RHEL	8	✅
RHEL	7	✅
Ubuntu	21	✅
Ubuntu	20	✅
Ubuntu	18	✅
Ubuntu	16	✅

Variables

• vars/tyk.yaml

Variable	Default	Comments
secrets.APISecret	352d20ee67be67f6340b4c0605b044b7	API secret
secrets.AdminSecret	12345	Admin secret
redis.host		Redis server host if different than the hosts url
redis.port	6379	Redis server listening port
redis.pass		Redis server password
redis.enableCluster	false	Enable if redis is running in cluster mode
redis.storage.database	0	Redis server database
redis.tls	false	Enable if redis connection is secured with SSL
mongo.host		MongoDB server host if different than the hosts url
mongo.port	27017	MongoDB server listening port
mongo.tls	false	Enable if mongo connection is secured with SSL
pgsql.host		PGSQL server host if different than the hosts url
pgsql.port	5432	PGSQL server listening port
pgsql.tls	false	Enable if pgsql connection is secured with SSL
dash.license		Dashboard license
dash.service.host		Dashboard server host if different than the hosts url
dash.service.port	3000	Dashboard server listening port
dash.service.proto	http	Dashboard server protocol
dash.service.tls	false	Set to true to enable SSL connections
gateway.service.host		Gateway server host if different than the hosts url
gateway.service.port	8080	Gateway server listening port
gateway.service.proto	http	Gateway server protocol
gateway.service.tls	false	Set to true to enable SSL connections
gateway.sharding.enabled	false	Set to true to enable filtering (sharding) of APIs
gateway.sharding.tags		The tags to use when filtering (sharding) Tyk Gateway nodes. Tags are processed as OR operations. If you include a non-filter tag (e.g. an identifier such as node-id-1, this will become available to your Dashboard analytics)
gateway.rpc.connString		Use this setting to add the URL for your MDCB or load balancer host
gateway.rpc.useSSL	true	Set this option to true to use an SSL RPC connection
gateway.rpc.sslInsecureSkipVerify	true	Set this option to true to allow the certificate validation (certificate chain and hostname) to be skipped. This can be useful if you use a self-signed certificate
gateway.rpc.rpcKey		Your organization ID to connect to the MDCB installation
gateway.rpc.apiKey		This the API key of a user used to authenticate and authorize the Gateway’s access through MDCB. The user should be a standard Dashboard user with minimal privileges so as to reduce any risk if the user is compromised. The suggested security settings are read for Real-time notifications and the remaining options set to deny
gateway.rpc.groupId		This is the zone that this instance inhabits, e.g. the cluster/data-center the Gateway lives in. The group ID must be the same across all the Gateways of a data-center/cluster which are also sharing the same Redis instance. This ID should also be unique per cluster (otherwise another Gateway cluster can pick up your keyspace events and your cluster will get zero updates).

• vars/redis.yaml

Variable	Default	Comments
redis_bind_interface	0.0.0.0	Binding address of Redis

Read more about Redis configuration here.

• vars/mongodb.yaml

Variable	Default	Comments
bind_ip	0.0.0.0	Binding address of MongoDB
mongodb_version	4.4	MongoDB version

Read more about MongoDB configuration here.

• vars/pgsql.yaml

Variable	Default	Comments
postgresql_databases[]	[]	Array of DBs to be created
postgresql_databases[].name	tyk_analytics	Database name
postgresql_users[]	[]	Array of users to be created
postgresql_users[0].name	default	User name
postgresql_users[0].password	topsecretpassword	User password
postgresql_global_config_options[]	[]	Postgres service config options
postgresql_global_config_options[1].option	listen_addresses	Listen address binding for the service
postgresql_global_config_options[1].value	*	Default value to listen to all addresses
postgresql_hba_entries[]	[]	Host based authenticaiton list
postgresql_hba_entries[4].type	host	Entry type
postgresql_hba_entries[4].database	tyk_analytics	Which database this entry will give access to
postgresql_hba_entries[4].user	default	What users this gain access from this entry
postgresql_hba_entries[4].address	0.0.0.0/0	What addresses this gain access from this entry
postgresql_hba_entries[4].auth_method	md5	What authentication method to to use for the users

Read more about PostgreSQL configuration here.

Install using Bootstrap CLI

To list the available flags, execute tyk-analytics bootstrap -h:

   usage: tyk-analytics bootstrap [<flags>]
   
   Bootstrap the Dashboard.
   
   Flags:
     -h, --help                 Show context-sensitive help (also try --help-long and --help-man).
         --version              Show application version.
         --conf="tyk_analytics.conf"  
                                Load a named configuration file.
         --create-org           Create a new organisation.
         --reuse-org=REUSE-ORG  Reuse the organisation with given ID.
         --drop-org=DROP-ORG    Drop the organisation with given ID.

Description

The bootstrap command makes bootstrapping easier. It helps you to create organizations and users. The command needs a config file path. By default, it looks at tyk_analytics.conf in the directory where the tyk-analytics binary is located. For example:

tyk-analytics bootstrap

You can also give the path of a custom config file with the --conf flag. For example:

tyk-analytics bootstrap --conf some-directory/custom.conf

The tool can work in both auto and interactive modes. You can use the flags while running the command or you can just run it without flags and use interactive mode.

Environment Variables

You can override the config values by environment variables. See how to configure an environment variable.

For example, you can override hostname, port, mongo url, redis host and redis port values by exporting the following variables:

• TYK_DB_HOSTCONFIG_HOSTNAME
• TYK_DB_LISTENPORT
• TYK_DB_MONGOURL
• TYK_DB_REDISHOST
• TYK_DB_REDISPORT

Install on Heroku

Install Tyk API Gateway on Heroku

A full Tyk Self-Managed installation can be deployed to Heroku dynos and workers using Heroku Container Registry and Runtime functionality. This guide will utilize Tyk Docker images with a small amount of customization as well as an external MongoDB service.

Prerequisites

1. Docker daemon installed and running locally
2. Heroku account, the free plan is sufficient for a basic PoC but not recommended for production usage
3. Heroku CLI installed
4. MongoDB service (such as Atlas, mLab, or your own deployment), this guide is based on MongoDB Atlas but others should work as well
5. Tyk License (note that in case of running multiple gateway dynos, license type must match)
6. Checkout the Tyk quickstart repository from GitHub
7. Python 2 or 3 in order to execute the bootstrap script

Creating Heroku Apps

We will create two Heroku apps, one for the Tyk Gateway (with Redis add-on attached to it) and another for the Dashboard and Pump.

Given Heroku CLI is installed and your Heroku account is available, log into it:

heroku login

Now create the Gateway app and note down its name:

heroku create

Creating app... done, ⬢ infinite-plains-14949
https://infinite-plains-14949.herokuapp.com/ | https://git.heroku.com/infinite-plains-14949.git

--space flag must be added to the command if the app is being created in a private space, see more details in the section on Heroku private spaces (below).

Provision a Redis add-on (we’ll use a hobby-dev plan for demonstration purposes but that’s not suitable for production), replacing the app name with your own:

heroku addons:create heroku-redis:hobby-dev -a infinite-plains-14949

Creating heroku-redis:hobby-dev on ⬢ infinite-plains-14949... free
Your add-on should be available in a few minutes.
! WARNING: Data stored in hobby plans on Heroku Redis are not persisted.
redis-infinite-35445 is being created in the background. The app will restart when complete...
Use heroku addons:info redis-infinite-35445 to check creation progress
Use heroku addons:docs heroku-redis to view documentation

Once add-on provisioning is done, the info command (replacing the add-on name with your own) will show the following output:

heroku addons:info redis-infinite-35445

=== redis-infinite-35445
Attachments:  infinite-plains-14949::REDIS
Installed at: Sun May 18 2018 14:23:21 GMT+0300 (EEST)
Owning app:   infinite-plains-14949
Plan:         heroku-redis:hobby-dev
Price:        free
State:        created

Time to create the Dashboard app and note down its name as well:

heroku create

Creating app... done, ⬢ evening-beach-40625
https://evening-beach-40625.herokuapp.com/ | https://git.heroku.com/evening-beach-40625.git

Since the Dashboard and Pump need access to the same Redis instance as the gateway, we’ll need to share the Gateway app’s add-on with this new app:

heroku addons:attach infinite-plains-14949::REDIS -a evening-beach-40625

Attaching redis-infinite-35445 to ⬢ evening-beach-40625... done
Setting REDIS config vars and restarting ⬢ evening-beach-40625... done, v3

To check that both apps have access to the same Redis add-on, we can utilize the heroku config command and check for the Redis endpoint:

heroku config -a infinite-plains-14949 | grep REDIS_URL
heroku config -a evening-beach-40625 | grep REDIS_URL

Their outputs should match.

Deploy the Dashboard

It’s recommended to start with the Dashboard so in your Heroku quickstart clone run:

cd analytics
ls dashboard

bootstrap.sh  Dockerfile.web  entrypoint.sh  tyk_analytics.conf

You will find it contains a Dockerfile.web for the web dyno, a config file for the Dashboard, entrypoint script for the Docker container and a bootstrap script for seeding the dashboard instance with sample data. All these files are editable for your purposes but have sane defaults for a PoC.

You can use the FROM statement in Dockerfile.web to use specific dashboard version and upgrade when needed instead of relying on the latest tag.

The Dashboard configuration can be changed by either editing the tyk_analytics.conf file or injecting them as environment variables via heroku config. In this guide we’ll use the latter for simplicity of demonstration but there is merit to both methods.

First let’s set the license key:

heroku config:set TYK_DB_LICENSEKEY="your license key here" -a evening-beach-40625

Setting TYK_DB_LICENSEKEY and restarting ⬢ evening-beach-40625... done, v4
TYK_DB_LICENSEKEY: should show your license key here

Now the MongoDB endpoint (replacing with your actual endpoint):

heroku config:set TYK_DB_MONGOURL="mongodb://user:[e-mail]:27017,mongosecondary.net:27017,mongotertiary.net:27017" -a evening-beach-40625

Setting TYK_DB_MONGOURL and restarting ⬢ evening-beach-40625... done, v5
TYK_DB_MONGOURL: mongodb://user:[e-mail]:27017,mongosecondary.net:27017,mongotertiary.net:27017

And enable SSL for it if your service supports/requires this:

heroku config:set TYK_DB_MONGOUSESSL="true" -a evening-beach-40625

Setting TYK_DB_MONGOUSESSL and restarting ⬢ evening-beach-40625... done, v6
TYK_DB_MONGOUSESSL: true

Since the Tyk Dashboard needs to access gateways sometimes, we’ll need to specify the Gateway endpoint too, which is the Gateway app’s URL:

heroku config:set TYK_DB_TYKAPI_HOST="https://infinite-plains-14949.herokuapp.com" -a evening-beach-40625
heroku config:set TYK_DB_TYKAPI_PORT="443" -a evening-beach-40625

Setting TYK_DB_TYKAPI_HOST and restarting ⬢ evening-beach-40625... done, v7
TYK_DB_TYKAPI_HOST: https://infinite-plains-14949.herokuapp.com
Setting TYK_DB_TYKAPI_PORT and restarting ⬢ evening-beach-40625... done, v8
TYK_DB_TYKAPI_PORT: 443

This is enough for a basic Dashboard setup but we recommend also changing at least node and admin secrets with strong random values, as well as exploring other config options.

Since the Tyk Pump is also a part of this application (as a worker process), we’ll need to configure it too.

ls pump

Dockerfile.pump  entrypoint.sh  pump.conf

Same principles apply here as well. Here we’ll need to configure MongoDB endpoints for all the Pumps (this can also be done in the pump.conf file):

heroku config:set PMP_MONGO_MONGOURL="mongodb://user:[e-mail]:27017,mongosecondary.net:27017,mongotertiary.net:27017" -a evening-beach-40625
heroku config:set PMP_MONGO_MONGOUSESSL="true"

heroku config:set PMP_MONGOAGG_MONGOURL="mongodb://user:[e-mail]:27017,mongosecondary.net:27017,mongotertiary.net:27017" -a evening-beach-40625
heroku config:set PMP_MONGOAGG_MONGOUSESSL="true"

With the configuration in place it’s finally time to deploy our app to Heroku.

First, make sure CLI is logged in to Heroku containers registry:

heroku container:login

Login Succeeded

Provided you’re currently in analytics directory of the quickstart repo:

heroku container:push --recursive -a evening-beach-40625

=== Building web (/tyk-heroku-docker/analytics/dashboard/Dockerfile.web)
Sending build context to Docker daemon  8.192kB
Step 1/5 : FROM tykio/tyk-dashboard:v1.6.1
 ---> fdbc67b43139
Step 2/5 : COPY tyk_analytics.conf /opt/tyk-dashboard/tyk_analytics.conf
 ---> 89be9913798b
Step 3/5 : COPY entrypoint.sh /opt/tyk-dashboard/entrypoint.sh
 ---> c256152bff29
Step 4/5 : ENTRYPOINT ["/bin/sh", "-c"]
 ---> Running in bc9fe7a569c0
Removing intermediate container bc9fe7a569c0
 ---> f40e6b259230
Step 5/5 : CMD ["/opt/tyk-dashboard/entrypoint.sh"]
 ---> Running in 705273810eea
Removing intermediate container 705273810eea
 ---> abe9f10e8b21
Successfully built abe9f10e8b21
Successfully tagged registry.heroku.com/evening-beach-40625/web:latest
=== Building pump (/tyk-heroku-docker/analytics/pump/Dockerfile.pump)
Sending build context to Docker daemon   5.12kB
Step 1/5 : FROM tykio/tyk-pump-docker-pub:v0.5.2
 ---> 247c6b5795a9
Step 2/5 : COPY pump.conf /opt/tyk-pump/pump.conf
 ---> 1befeab8f092
Step 3/5 : COPY entrypoint.sh /opt/tyk-pump/entrypoint.sh
 ---> f8ad0681aa70
Step 4/5 : ENTRYPOINT ["/bin/sh", "-c"]
 ---> Running in 0c30d35b9e2b
Removing intermediate container 0c30d35b9e2b
 ---> b17bd6a8ed44
Step 5/5 : CMD ["/opt/tyk-pump/entrypoint.sh"]
 ---> Running in a16acb453b62
Removing intermediate container a16acb453b62
 ---> 47ac9f221d8d
Successfully built 47ac9f221d8d
Successfully tagged registry.heroku.com/evening-beach-40625/pump:latest
=== Pushing web (/tyk-heroku-docker/analytics/dashboard/Dockerfile.web)
The push refers to repository [registry.heroku.com/evening-beach-40625/web]
c60cf00e6e9b: Pushed 
11d074829795: Pushed 
8b72aa2b2acc: Pushed 
ca2feecf234c: Pushed 
803aafd71223: Pushed 
43efe85a991c: Pushed 
latest: digest: sha256:b857afaa69154597558afb2462896275ab667b729072fac224487f140427fa73 size: 1574
=== Pushing pump (/tyk-heroku-docker/analytics/pump/Dockerfile.pump)
The push refers to repository [registry.heroku.com/evening-beach-40625/pump]
eeddc94b8282: Pushed 
37f3b3ce56ab: Pushed 
4b61531ec7dc: Pushed 
eca9efd615d9: Pushed 
0f700064c5a1: Pushed 
43efe85a991c: Mounted from evening-beach-40625/web 
latest: digest: sha256:f45acaefa3b47a126dd784a888c89e420814ad3031d3d4d4885e340a59aec31c size: 1573

This has built Docker images for both dashboard and pump, as well as pushed them to Heroku registry and automatically deployed to the application.

Provided everything went well (and if not, inspect the application logs), you should be seeing the Dashboard login page at your app URL (e.g “https://evening-beach-40625.herokuapp.com/”).

However, it doesn’t yet have any accounts. It order to populate it please run the dashboard/bootstrap.sh script:

dashboard/bootstrap.sh evening-beach-40625.herokuapp.com

Creating Organization
ORGID: 5b016ca530867500050b9e90
Adding new user
USER AUTH: a0f7c1e878634a60599dc037489a880f
NEW ID: 5b016ca6dcd0056d702dc40e
Setting password

DONE
====
Login at https://evening-beach-40625.herokuapp.com/
User: [e-mail]
Pass: test123

It will generate a default organization with random admin username and a specified password. The bootstrap script can be edited to suit your needs as well as just editing the user info in the dashboard.

If this was successful, you should be able to log into your dashboard now.

The last step in this app is to start the Pump worker dyno since by default only the web dyno is enabled:

heroku dyno:scale pump=1 -a evening-beach-40625

Scaling dynos... done, now running pump at 1:Free

At that point the dyno formation should look like this:

heroku dyno:scale -a evening-beach-40625

pump=1:Free web=1:Free

Deploy the Gateway

The process is very similar for the Tyk Gateway, except it doesn’t have a worker process and doesn’t need access to MongoDB.

cd ../gateway
ls

Dockerfile.web  entrypoint.sh  tyk.conf

All these files serve the same purpose as with the Dasboard and the Pump. Configuration can either be edited in tyk.conf or injected with heroku config.

To get things going we’ll need to set following options for the Dashboard endpoint (substituting the actual endpoint and the app name, now for the gateway app):

heroku config:set TYK_GW_DBAPPCONFOPTIONS_CONNECTIONSTRING="https://evening-beach-40625.herokuapp.com" -a infinite-plains-14949
heroku config:set TYK_GW_POLICIES_POLICYCONNECTIONSTRING="https://evening-beach-40625.herokuapp.com" -a infinite-plains-14949

Setting TYK_GW_DBAPPCONFOPTIONS_CONNECTIONSTRING and restarting ⬢ infinite-plains-14949... done, v4
TYK_GW_DBAPPCONFOPTIONS_CONNECTIONSTRING: https://evening-beach-40625.herokuapp.com
Setting TYK_GW_POLICIES_POLICYCONNECTIONSTRING and restarting ⬢ infinite-plains-14949... done, v5
TYK_GW_POLICIES_POLICYCONNECTIONSTRING: https://evening-beach-40625.herokuapp.com

Since the Redis configuration will be automatically discovered (it’s already injected by Heroku), we’re ready to deploy:

heroku container:push --recursive -a infinite-plains-14949

=== Building web (/tyk-heroku-docker/gateway/Dockerfile.web)
Sending build context to Docker daemon  6.144kB
Step 1/5 : FROM tykio/tyk-gateway:v2.6.1
 ---> f1201002e0b7
Step 2/5 : COPY tyk.conf /opt/tyk-gateway/tyk.conf
 ---> b118611dc36b
Step 3/5 : COPY entrypoint.sh /opt/tyk-gateway/entrypoint.sh
 ---> 68ad364030cd
Step 4/5 : ENTRYPOINT ["/bin/sh", "-c"]
 ---> Running in 859f4c15a0d2
Removing intermediate container 859f4c15a0d2
 ---> 5f8c0d1b378a
Step 5/5 : CMD ["/opt/tyk-gateway/entrypoint.sh"]
 ---> Running in 44c5e4c87708
Removing intermediate container 44c5e4c87708
 ---> 86a9eb509968
Successfully built 86a9eb509968
Successfully tagged registry.heroku.com/infinite-plains-14949/web:latest
=== Pushing web (/tyk-heroku-docker/gateway/Dockerfile.web)
The push refers to repository [registry.heroku.com/infinite-plains-14949/web]
b8a4c3e3f93c: Pushed 
0b7bae5497cd: Pushed 
e8964f363bf4: Pushed 
379aae48d347: Pushed 
ab2b28b92877: Pushed 
021ee50b0983: Pushed 
43efe85a991c: Mounted from evening-beach-40625/pump 
latest: digest: sha256:d67b8f55d729bb56e06fe38e17c2016a36f2edcd4f01760c0e62a13bb3c9ed38 size: 1781

Inspect the logs (heroku logs -a infinite-plains-14949) to check that deployment was successful, also the node should be registered by the Dashboard in “System Management” -> “Nodes and Licenses” section.

You’re ready to follow the guide on creating and managing your APIs with this Heroku deployment.

To use the geographic log distribution feature in the Dashboard please supply the GeoLite2 DB in the gateway directory, uncomment the marked line in Dockerfile.web and set the analytics_config.enable_geo_ip setting (or TYK_GW_ANALYTICSCONFIG_ENABLEGEOIP env var) to true.

Heroku Private Spaces

Most instructions are valid for Heroku Private Spaces runtime. However there are several differences to keep in mind.

Heroku app creation commands must include the private space name in the --space flag, e.g.:

heroku create --space test-space-virginia

When deploying to the app, the container must be released manually after pushing the image to the app:

heroku container:push --recursive -a analytics-app-name
heroku container:release web -a analytics-app-name
heroku container:release pump -a analytics-app-name

Similarly, the Gateway:

heroku container:push --recursive -a gateway-app-name
heroku container:release web -a gateway-app-name

Please allow several minutes for the first deployment to start as additional infrastructure is being created for it. Next deployments are faster.

Private spaces maintain stable set of IPs that can be used for allowing fixed set of IPs on your upstream side (e.g. on an external database service). Find them using the following command:

heroku spaces:info --space test-space-virginia

Alternatively VPC peering can be used with the private spaces if external service supports it. This way exposure to external network can be avoided. For instance, see MongoDB Atlas guide for setting this up.

The minimal Heroku Redis add-on plan that installs into your private space is currently private-7. Please refer to Heroku’s Redis with private spaces guide for more information.

Apps in private spaces don’t enable SSL/TLS by default. It needs to be configured in the app settings along with the domain name for it. If it’s not enabled, please make sure that configs that refer to corresponding hosts are using HTTP instead of HTTPS and related ports (80 for HTTP).

Gateway Plugins

In order to enable rich plugins for the Gateway, please set the following Heroku config option to either python or lua depending on the type of plugins used:

heroku config:set TYK_PLUGINS="python" -a infinite-plains-14949

Setting TYK_PLUGINS and restarting ⬢ infinite-plains-14949... done, v9
TYK_PLUGINS: python

After re-starting the Gateway, the logs should be showing something similar to this:

2018-05-18T13:13:50.272511+00:00 app[web.1]: Tyk will be using python plugins
2018-05-18T13:13:50.311510+00:00 app[web.1]: time="May 18 13:13:50" level=info msg="Setting PYTHONPATH to 'coprocess/python:middleware/python:event_handlers:coprocess/python/proto'"
2018-05-18T13:13:50.311544+00:00 app[web.1]: time="May 18 13:13:50" level=info msg="Initializing interpreter, Py_Initialize()"
2018-05-18T13:13:50.497815+00:00 app[web.1]: time="May 18 13:13:50" level=info msg="Initializing dispatcher"

Set this variable back to an empty value in order to revert back to the default behavior.

Upgrading or Customizing Tyk

Since this deployment is based on Docker images and containers, upgrading or making changes to the deployment is as easy as building a new image and pushing it to the registry.

Specifically, upgrading version of any Tyk components is done by editing the corresponding Dockerfile and replacing the base image version tag. E.g. changing FROM tykio/tyk-gateway:v2.5.4 to FROM tykio/tyk-gateway:v2.6.1 will pull the Tyk gateway 2.6.1. We highly recommend specifying concrete version tags instead of latest for better house keeping.

Once these changes have been made just run heroku container:push --recursive -a app_name on the corresponding directory as shown previously in this guide. This will do all the building and pushing as well as gracefully deploying on your Heroku app.

Please refer to Heroku documentation on containers and registry for more information.

Install on Microsoft Azure

Azure is Microsoft’s cloud services platform. It supports both the running of Ubuntu Servers, as well as Docker and Docker-Compose.

For more details, see the Azure Documentation.

**Tyk Installation Options for Azure **

Azure allows you to install Tyk in the following ways:

On-Premises

1. Via our Ubuntu Setup on an installed Ubuntu Server on Azure.
2. Via our Docker Installation using Azure’s Docker support.

See our video for installing Tyk on Ubuntu via Azure:

We also have a blog post that walks you through installing Tyk on Azure.

Install to Google Cloud

GCP is Google’s Cloud services platform. It supports both the running of Ubuntu Servers and Docker.

For more details, see the Google Cloud Documentation.

**Tyk Installation Options for Google CLoud **

Google Cloud allows you to install Tyk in the following ways:

On-Premises

1. Via our Ubuntu Setup on an installed Ubuntu Server within Google Cloud.
2. Via our Docker Installation using Google Cloud’s Docker support.

Tyk Pump on GCP

When running Tyk Pump in GCP using Cloud Run it is available 24/7. However, since it is serverless you also need to ensure that the CPU always allocated option is configured to ensure availability of the analytics. Otherwise, for each request there will be a lag between the Tyk Pump container starting up and having the CPU allocated. Subsequently, the analytics would only be available during this time.

1. Configure Cloud Run to have the CPU always allocated option enabled. Otherwise, the Tyk Pump container needs to warm up, which takes approximately 1 min. Subsequently, by this time the stats are removed from Redis.

2. Update the Tyk Gateway configuration to keep the stats for 3 mins to allow Tyk Pump to process them. This value should be greater than the Pump purge delay to ensure the analytics data exists long enough in Redis to be processed by the Pump.