Tyk Opensource Gateway v5.5.0 not able to start properly

Support
1

Hi,

I tried to deploy Tyk Opensource Gateway v5.5.0 using docker compose by referring to this repo ( GitHub - TykTechnologies/tyk-gateway-docker: Docker compose deployment to run Tyk OSS Gateway.

I used 2 servers: one is Unbuntu 22.04, and another is Amazon Linux 2023 to deploy this v5.5.0 tyk gateway. Both servers have not installed Tyk before. Here are the info about these 2 servers:

docker version → ubuntu

Client:
Version: 28.2.2
API version: 1.50
Go version: go1.23.1
Git commit: 28.2.2-0ubuntu1~22.04.1
Built: Wed Sep 10 14:50:16 2025
OS/Arch: linux/amd64
Context: default

Server:
Engine:
Version: 28.2.2
API version: 1.50 (minimum version 1.24)
Go version: go1.23.1
Git commit: 28.2.2-0ubuntu1~22.04.1
Built: Wed Sep 10 14:50:16 2025
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.28
GitCommit:
runc:
Version: 1.3.3-0ubuntu1~22.04.3
GitCommit:
docker-init:
Version: 0.19.0
GitCommit:

Docker Compose version v5.0.2

release info → ubuntu

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION=“Ubuntu 22.04.5 LTS”
PRETTY_NAME=“Ubuntu 22.04.5 LTS”
NAME=“Ubuntu”
VERSION_ID=“22.04”
VERSION=“22.04.5 LTS (Jammy Jellyfish)”
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL=“https://www.ubuntu.com/”
SUPPORT_URL=“https://help.ubuntu.com/”
BUG_REPORT_URL=“Bugs : Ubuntu”
PRIVACY_POLICY_URL=“Data privacy | Ubuntu and Canonical Legal”
UBUNTU_CODENAME=jammy

docker version → amazon Linux 2023

Client:
Version: 25.0.5
API version: 1.44
Go version: go1.22.5
Git commit: 5dc9bcc
Built: Wed Aug 21 00:00:00 2024
OS/Arch: linux/amd64
Context: default

Server:
Engine:
Version: 25.0.6
API version: 1.44 (minimum version 1.24)
Go version: go1.22.5
Git commit: b08a51f
Built: Wed Aug 21 00:00:00 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.25
GitCommit: bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
runc:
Version: 1.2.4
GitCommit: 6c52b3fc541fb26fe8c374d5f58112a0a5dbda66
docker-init:
Version: 0.19.0
GitCommit: de40ad0

Docker Compose version v5.0.2

release info → Amazon Linux 2023

Amazon Linux release 2023.6.20250211 (Amazon Linux)
NAME=“Amazon Linux”
VERSION=“2023”
ID=“amzn”
ID_LIKE=“fedora”
VERSION_ID=“2023”
PLATFORM_ID=“platform:al2023”
PRETTY_NAME=“Amazon Linux 2023.6.20250211”
ANSI_COLOR=“0;33”
CPE_NAME=“cpe:2.3:o:amazon:amazon_linux:2023”
HOME_URL=“Linux for the Cloud – Amazon Linux 2023 – Amazon Web Services”
DOCUMENTATION_URL=“https://docs.aws.amazon.com/linux/”
SUPPORT_URL=“AI-powered cloud support – AWS Support plans – AWS”
BUG_REPORT_URL=“GitHub - amazonlinux/amazon-linux-2023: Amazon Linux 2023”
VENDOR_NAME=“AWS”
VENDOR_URL=“https://aws.amazon.com/”
SUPPORT_END=“2029-06-30”
Amazon Linux release 2023.6.20250211 (Amazon Linux)

when I run ‘docker compose up -d’ at Ubuntu 22.04, the tyk container couldn’t be started. The error logs say ‘storage: Redis is either down or was not configured’. But the redis container is up and running.

Here are some of the logs:

time=“Feb 11 07:58:55” level=info msg=“Tyk API Gateway 5.5.0” prefix=main
time=“Feb 11 07:58:55” level=warning msg=“Insecure configuration allowed” config.allow_insecure_configs=true prefix=checkup
time=“Feb 11 07:58:55” level=error msg=“storage: Redis is either down or was not configured”
time=“Feb 11 07:58:55” level=error msg=“storage: Redis is either down or was not configured”
time=“Feb 11 07:58:55” level=error msg=“cannot set key in pollerCacheKey” error=“storage: Redis is either down or was not configured”
time=“Feb 11 07:58:55” level=info msg=“Starting Poller” prefix=host-check-mgr
time=“Feb 11 07:58:55” level=error msg=“storage: Redis is either down or was not configured”
time=“Feb 11 07:58:55” level=error msg=“Could not set version in versionStore” error=“storage: Redis is either down or was not configured” prefix=main
time=“Feb 11 07:58:55” level=info msg=“PIDFile location set to: /var/run/tyk/tyk-gateway.pid” prefix=main
time=“Feb 11 07:58:55” level=warning msg=“The control_api_port should be changed for production” prefix=main
time=“Feb 11 07:58:55” level=info msg=“Initialising Tyk REST API Endpoints” prefix=main
time=“Feb 11 07:58:55” level=info msg=“job run successful” name=purge-oauth-tokens prefix=scheduler
time=“Feb 11 07:58:55” level=error msg=“storage: Redis is either down or was not configured”
time=“Feb 11 07:58:55” level=error msg=“Connection to Redis failed, reconnect in 10s” error=“storage: Redis is either down or was not configured” prefix=pub-sub

ubuntu_tyk
ubuntu_tyk1262×873 191 KB

When I run ‘docker compose up -d’ at Amazon Linux 2023, tyk container can be running properly. However, when I run ‘docker compose down -v’, and run again ‘docker compose up -d’, the tyk container also cannot be started. And it shows the same error logs saying “storage: Redis is either down or was not configured”.

amazon_linux_tyk
amazon_linux_tyk1262×1007 220 KB

Unfortunately, I didn’t have the screenshot of the tyk container was running during first deployment at Amazon Linux 2023.

I am not sure why the Tyk gateway v5.5.0 couldn’t be started properly at these 2 servers. Is there any step that I missed?

Regards,

Maan Tarng

2

Hi,

I’m sorry you’ve encountered this issue.

I’ve tried to reproduce it myself and been unable to even on Amazon linux 2023.

Is it possible that the tyk.standalone.conf has been changed? That might cause the gateway to not start and if the redis config in there was changed the gateway would not connect to the redis started via the compose file.

However the gateway won’t exit because it can’t contact redis. It won’t function correctly either but it will keep trying to establish a connection. For example, it will perpetually give these errors:

level=error msg=“storage: Redis is either down or was not configured”
level=error msg=“storage: Redis is either down or was not configured”
level=error msg=“storage: Redis is either down or was not configured”
level=error msg=“storage: Redis is either down or was not configured”

So the fact that your gateway isn’t starting at all suggests an issue with the system. Could it be very resource constrained? It would be helpful to have both the docker service logs from systemd and the logs from the gateway container that is exited.

Cheers,
Pete

3

Hi Pete,

I used the same tyk.standalone.conf from this link( tyk-gateway-docker/tyk.standalone.conf at master · TykTechnologies/tyk-gateway-docker · GitHub, and didn’t change it.

tyk.standalone.conf

{
“log_level”: “info” ,
“listen_port”: 8080,
“secret”: “352d20ee67be67f6340b4c0605b044b7”,
“template_path”: “/opt/tyk-gateway/templates”,
“tyk_js_path”: “/opt/tyk-gateway/js/tyk.js”,
“middleware_path”: “/opt/tyk-gateway/middleware”,
“use_db_app_configs”: false,
“app_path”: “/opt/tyk-gateway/apps/”,
“storage”: {
“type”: “redis”,
“host”: “tyk-redis”,
“port”: 6379,
“username”: “”,
“password”: “”,
“database”: 0,
“optimisation_max_idle”: 2000,
“optimisation_max_active”: 4000
},
“enable_analytics”: false,
“analytics_config”: {
“type”: “”,
“ignored_ips”:
},
“health_check”: {
“enable_health_checks”: false,
“health_check_value_timeouts”: 60
},
“enable_non_transactional_rate_limiter”: true,
“enable_sentinel_rate_limiter”: false,
“enable_redis_rolling_limiter”: false,
“allow_master_keys”: false,
“policies”: {
“policy_source”: “file”,
“policy_path”: “/opt/tyk-gateway/policies”
},
“hash_keys”: true,
“close_connections”: false,
“http_server_options”: {
“enable_websockets”: true
},
“allow_insecure_configs”: true,
“coprocess_options”: {
“enable_coprocess”: true,
“coprocess_grpc_server”: “”
},
“enable_bundle_downloader”: true,
“bundle_base_url”: “”,
“global_session_lifetime”: 100,
“force_global_session_lifetime”: false,
“max_idle_connections_per_host”: 500,
“enable_jsvm”: true
}

Currently, the system resource is 1 cpu, and the memory info is like this:

           total        used        free      shared  buff/cache   available

Mem: 1905 650 177 5 1077 1020
Swap: 0 0 0

I checked again the tyk container logs, the error logs are still the same “storage: Redis is either down or was not configured”. There is warning logs saying “Number of CPUs 1 is too low for production use. A minimum of 2 is recommended”. But I guess since it is a warning logs, it will not cause the container to exit, right?

sample logs from tyk container

time=“Feb 13 01:03:22” level=info msg=“Tyk API Gateway 5.5.0” prefix=main
time=“Feb 13 01:03:22” level=warning msg=“Insecure configuration allowed” config.allow_insecure_configs=true prefix=checkup
time=“Feb 13 01:03:22” level=warning msg=“Number of CPUs 1 is too low for production use. A minimum of 2 is recommended.\n\tThis could have a significant negative impact on performance.\n\tPlease refer to the following link for further guidance:\n\t\tPlanning for Production - Tyk Documentation” prefix=checkup
time=“Feb 13 01:03:22” level=error msg=“storage: Redis is either down or was not configured”
time=“Feb 13 01:03:22” level=error msg=“Could not set version in versionStore” error=“storage: Redis is either down or was not configured” prefix=main
time=“Feb 13 01:03:22” level=error msg=“storage: Redis is either down or was not configured”
time=“Feb 13 01:03:22” level=error msg=“storage: Redis is either down or was not configured”
time=“Feb 13 01:03:22” level=error msg=“cannot set key in pollerCacheKey” error=“storage: Redis is either down or was not configured”
time=“Feb 13 01:03:22” level=info msg=“Starting Poller” prefix=host-check-mgr
time=“Feb 13 01:03:22” level=info msg=“PIDFile location set to: /var/run/tyk/tyk-gateway.pid” prefix=main
time=“Feb 13 01:03:22” level=warning msg=“The control_api_port should be changed for production” prefix=main
time=“Feb 13 01:03:22” level=info msg=“Initialising Tyk REST API Endpoints” prefix=main
time=“Feb 13 01:03:22” level=info msg=“–> Standard listener (http)” port=“:8080” prefix=main
time=“Feb 13 01:03:22” level=warning msg=“Starting HTTP server on:[::]:8080” prefix=main
time=“Feb 13 01:03:22” level=info msg=“[RATELIMIT] DRL with Redis Rate Limiter enabled (using pipeline)”
time=“Feb 13 01:03:22” level=info msg=“Initialising distributed rate limiter” prefix=main
time=“Feb 13 01:03:22” level=info msg=“Tyk Gateway started (5.5.0)” prefix=main
time=“Feb 13 01:03:22” level=info msg=“–> Listening on address: (open interface)” prefix=main
time=“Feb 13 01:03:22” level=info msg=“–> Listening on port: 8080” prefix=main
time=“Feb 13 01:03:22” level=info msg=“–> PID: 1” prefix=main
time=“Feb 13 01:03:22” level=info msg=“Starting gateway rate limiter notifications…”
time=“Feb 13 01:03:22” level=error msg=“storage: Redis is either down or was not configured”
time=“Feb 13 01:03:22” level=error msg=“storage: Redis is either down or was not configured”
time=“Feb 13 01:03:22” level=error msg=“Connection to Redis failed, reconnect in 10s” error=“storage: Redis is either down or was not configured” prefix=pub-sub

I tried to get the journalctl logs for docker, and tried to look for the error message:

Dec 30 18:08:58 itolb02 dockerd[1474]: time=“2025-12-30T18:08:58.188789228+08:00” level=warning msg=“CDI setup error /var/run/cdi: failed to monitor for changes: no such file or directory”
Dec 30 18:08:58 itolb02 dockerd[1474]: time=“2025-12-30T18:08:58.188824928+08:00” level=warning msg=“CDI setup error /etc/cdi: failed to monitor for changes: no such file or directory”
Jan 08 16:02:27 itolb02 dockerd[1597]: time=“2026-01-08T16:02:27.331321980+08:00” level=warning msg=“CDI setup error /var/run/cdi: failed to monitor for changes: no such file or directory”
Jan 08 16:02:27 itolb02 dockerd[1597]: time=“2026-01-08T16:02:27.331346380+08:00” level=warning msg=“CDI setup error /etc/cdi: failed to monitor for changes: no such file or directory”
Jan 22 09:19:02 itolb02 dockerd[1265]: time=“2026-01-22T09:19:02.513046825+08:00” level=warning msg=“CDI setup error /etc/cdi: failed to monitor for changes: no such file or directory”
Jan 22 09:19:02 itolb02 dockerd[1265]: time=“2026-01-22T09:19:02.513519429+08:00” level=warning msg=“CDI setup error /var/run/cdi: failed to monitor for changes: no such file or directory”
Feb 01 22:01:05 itolb02 dockerd[1265]: time=“2026-02-01T22:01:05.796580807+08:00” level=info msg=“stopping event stream following graceful shutdown” error=“” module=libcontainerd namespace=moby
Feb 01 22:01:37 itolb02 dockerd[775]: time=“2026-02-01T22:01:37.129537054+08:00” level=warning msg=“CDI setup error /var/run/cdi: failed to monitor for changes: no such file or directory”
Feb 01 22:01:37 itolb02 dockerd[775]: time=“2026-02-01T22:01:37.129560154+08:00” level=warning msg=“CDI setup error /etc/cdi: failed to monitor for changes: no such file or directory”
Feb 04 14:54:54 itolb02 dockerd[775]: time=“2026-02-04T14:54:54.921530342+08:00” level=error msg=“Failed to get event” error=“rpc error: code = Unavailable desc = error reading from server: EOF” module=libcontainerd namespace=moby
Feb 04 14:54:54 itolb02 dockerd[775]: time=“2026-02-04T14:54:54.921899143+08:00” level=error msg=“Failed to get event” error=“rpc error: code = Unavailable desc = error reading from server: EOF” module=libcontainerd namespace=plugins.moby
Feb 12 09:25:26 itolb02 dockerd[775]: time=“2026-02-12T09:25:26.876449066+08:00” level=info msg=“stopping event stream following graceful shutdown” error=“” module=libcontainerd namespace=moby
Feb 12 09:25:57 itolb02 dockerd[806]: time=“2026-02-12T09:25:57.059523694+08:00” level=warning msg=“CDI setup error /etc/cdi: failed to monitor for changes: no such file or directory”
Feb 12 09:25:57 itolb02 dockerd[806]: time=“2026-02-12T09:25:57.059573794+08:00” level=warning msg=“CDI setup error /var/run/cdi: failed to monitor for changes: no such file or directory”
Feb 12 14:25:23 itolb02 dockerd[806]: time=“2026-02-12T14:25:23.341747099+08:00” level=error msg=“Error setting up exec command in container 80d2bbfb9400: Container 80d2bbfb94005bcfd7964d0203848c751a7e48045bdc3241f53e4a10b796c958 is restarting, wait until the container is running”
Feb 12 14:29:08 itolb02 dockerd[806]: time=“2026-02-12T14:29:08.039283210+08:00” level=error msg=“Error setting up exec command in container f4dfe3d9fc8c: Container f4dfe3d9fc8c6cc88de078830ca4e401f8cf6c51f65b86453881cb96f527ba56 is restarting, wait until the container is running”
Feb 12 14:29:11 itolb02 dockerd[806]: time=“2026-02-12T14:29:11.623245994+08:00” level=error msg=“Error setting up exec command in container f4dfe3d9fc8c: Container f4dfe3d9fc8c6cc88de078830ca4e401f8cf6c51f65b86453881cb96f527ba56 is restarting, wait until the container is running”

I also tried to use systemctl to stop and start again docker, but still the same.

4

You’re right that the number of CPUs warning can be ignored but there must be a docker issue if the gateway can’t communicate with redis. It might be an idea to delete the networks and retry.

You could do docker container inspect to see why it exits. There are instructions for doing that here

We need to understand why the gateway exits, because not being able to contact redis won’t do that. But we also need to understand why the gateway can’t communication with redis.

Do I understand correctly that your Amazon 2023 instance has 2G of memory?

Cheers,
Pete

5

Hi @Pete

Thanks for your help and suggetion.

Now I found the reason why the Tyk container exited abnormally. It is because I put a Go plugin binary, which was compiled using tyk-plugin-compiler:v4.0.0 at at the middleware folder. Think this new tyk complains it, by showing this “fatal error”

tyk-plugin-error
tyk-plugin-error1882×250 19.7 KB

So, can I confirm that in order to use tyk plugin with this tyk gateway v5.5.0, I have to use this tyk-plugin-compiler:v5.5.0 to compile the Go plugin, and use it? Am I right?