Is there any way to install Tyk without REDIS? I don’t need to store tokens or have distributed caching or rate limiting. I want a simple, stateless installation that has a static config that is stored in GIT. Changes to the config would be deployed when there is a change in the GIT Main branch.
I really want to avoid the extra dependency of REDIS
Hi @Jonathan_Gurwitz, unfortunately, Tyk is dependant on Redis for now. Redis is used a performant key store for Tyk its not just for caching and storing API keys
What is stored in the key store? The tyk config? Is tyk stateful? I’m assessing Tyk vs Kong, KrakenD and other API gateways. All of the options which I have seen have a stateless mode which allows them to run in a single kubernetes pod without any dependencies on external systems such as Redis. Their config can be managed 100% in GIT.
Unfortunately Tyk can not run without Redis. We use the same gateway across all of our deployment models and there are features like DR, and caching that depend on it. Maybe we can have a stateless mode for a use case like yours but I have not personally seen much demand for stateless use. What is your use case here?
Regarding the Redis dependency, we have had internal discussions about potentially removing it. If you are interested, I can dig up more information on this matter.
I was just watching a training video you made so now I can put a face to the name 
My requirement is to have an API gateway solution without a single point of failure. Kong, API-Six and KrakenD run in a stateless mode so nothing short of a broken config would cause an outage. With Tyk, redis becomes a single point of failure. If redis goes down, the entire API infrastructure goes down.
Of course redis can be managed in the safest and most redundant way but if I have a choice, I would rather not have a single point of failure.
Hi,
This sounds very much like you just need a proxy, what API-specific features are you looking to implement?
As Zaid said there’s been some talk about a stateless version that doesn’t need redis, but when you strip out most APIM features that need a store - specifically security, access-control, throttling & rate-limiting what you end up with starts to look like a standard http proxy.
Would be great to great to understand your APIM-specific use cases that something simpler like Envoy or just vanilla NGINX couldn’t handle?
There are a few things which we want that don’t require storage
Payload schema validation
JWT signature verification
Authorization of routes based on claims in jwt
MTLS between the gateway and the backend
Circuit breaker
Routing to Lambda functions
Direct integration with queues (write message to queue from gateway)
Access logs
Mocking
IP whitelisting
Short lived tokens can be managed without storage. We generally don’t need to revoke tokens.
Distributed caching and distributed rate limiting are almost never required. We can rate limit per pod. It’s good enough to stop a DDOS attack.
Nice I’ll feed that back to our product team, since Tyk does in fact do most of those requirements.
Redis doesn’t store the Tyk configuration, only tokens, central SSL cert store (though file-based is supported), temporary analytics, cache data, it also provides a synchronisation mechanism to hot reload a cluster of gateways without restart.
I also believe that Tyk gateways keep trucking without redis, so the redis pod can be ephemeral (this is the case in our hybrid gateway deployment topology - it’s designed to handle dependency failures minimising service disruption.
If you do not need redis-dependent features then you should be able to get away with a lightweight ephemeral redis install, it shouldn’t be a SPOF.
One of the ways to implement it in past was having a docker image with single node Redis installed inside it, so Gateway will use this local redis inside the image, and from the outside it will look as stateless, and what you describe. Do you think it will fit your requirments, especially if we ship such image?
I was actually thinking the same thing but I didnt think you would want to make an official image just because I thought it was a good idea. I would definitely be willing to give this a try.
I don’t know how tyk behaves today if redis is down but the SPOF risk would be greatly mitigated if Tyk was able to start without redis and would continue running even if redis became unreachable or unresponsive. The only consequence could be that the distributed functionality stops working and a signal is generated which shows that the pod is running but in a limited capacity.
It will actually start without Redis just fine, and it designed to surive redis failures, and re-connect when it alive. If you start it now without Redis every 10 seconds you will start seeing this log message.
time="Aug 03 09:43:11" level=error msg="Redis health check failed" error="storage: Redis is either down or was not configured" liveness-check=true prefix=main time="Aug 03 09:43:11" level=error msg="Connection to Redis failed, reconnect in 10s" error="storage: Redis is either down or was not configured" prefix=pub-sub
BUT, functionality which you mentioned above should work just fine, except rate limiting. It will not work even within the single node. So at some sense Tyk do offer unofficial DB less setup, it is more like that we do not have it as part of our day to day QA testing, and we not cover in the docs which functionality will work without redis and which will. So it actually can be quite an easy documentation win + do not show log that redis down if redis db credentials are empty.
Ideally you would have a setting where Tyk doesn’t even try to connect to REDIS. TYK looks amazing and very feature rich compared to the other gateways but running stateless is supported by your competitors and is something that they highlight. Our platform team raised it as soon as I told them that Tyk was my current favourite choice for an API Gateway.
Yes, totally agree. As mentioned above, it should not connect to Redis, if redis credentials are empty. As simple as this.
I made the following PRs, trying to understand what is the “minimal” safe change to make it dbless, with limitations in mind. Allow running without Redis, without printing errors by buger · Pull Request #5384 · TykTechnologies/tyk · GitHub
I also generated docker image for this PR v5.2.0-rc3, which you can try out. You just need to set the following env variable to empty value: TYK_GW_STORAGE_TYPE=.
PS. while it mention v5.2.0, it doesn not mean it will be released there. It just to generate package for this thread.
2 Likes