Tyk as gateway without redis. Is it possbile? some config questions

Hi Tyk Community,

I need configure Tyk as service gateway. But without redis or any other DS. Most of question already closed. On the botom you can find my test API config file.

But still have some open question. I hope that you will be able provide me some advices.

  1. JWKS Caching. Does Tyk cache JWKS without redis by default. if not, is it possible to configure this caching without redis? At this moment looks like I got the following error every time when call Tyk
time="Dec 13 11:22:01" level=error msg="cannot set key in pollerCacheKey" error="storage: Redis is either down or was not configured"
  1. Rate limiting: I read about DRL and Redis rate limiter: Rate Limiting in Tyk
    Also found how to configure it on API level:Rate Limiting in Tyk
    it looks like enough add in the API config like:
    "global_rate_limit": {
        "rate": 5,
        "per": 60

but again: I got errors like:

time="Dec 13 13:08:53" level=error msg="Can't update session" api_id=1 api_name=bm-admin error="storage: Redis is either down or was not configured" org_id=1

does it try to use Redis rate limiter or DRL required Redis? Is it possible to configure without redis

api json config:

    "name": "test-app",
    "api_id": "1",
    "org_id": "1",
    "definition": {
        "location": "header",
        "key": "version"
    "version_data": {
        "not_versioned": true,
        "versions": {
            "Default": {
                "name": "Default",
                "expires": "3000-01-02 15:04",
                "use_extended_paths": true,
                "extended_paths": {
                    "ignored": [],
                    "white_list": [],
                    "black_list": [],
                    "circuit_breakers": [
                            "path": "/services",
                            "method": "POST",
                            "threshold_percent": 0.5,
                            "samples": 5,
                            "return_to_service_after": 60,
                            "disable_half_open_state": false
                "global_headers": {
                    "x-user": "$tyk_context.jwt_claims_sub"
    "enable_jwt": true,
    "jwt_signing_method": "rsa",
    "jwt_source": "https://dev-*******.us.auth0.com/.well-known/jwks.json",
    "jwt_identity_base_field": "sub",
    "jwt_client_base_field": "",
    "jwt_policy_field_name": "pol",
    "jwt_default_policies": [
    "proxy": {
        "listen_path": "/gateway/",
        "target_url": "env://TARGETURL",
        "strip_listen_path": true
    "enable_batch_request_support": true,
    "active": true,
    "enable_context_vars": true,
    "disable_rate_limit": false,
    "global_rate_limit": {
        "rate": 5,
        "per": 60

Hi - thanks for the questions.

Redis is a dependency for the Tyk gateway for all functionality.

If you want to make use of the Tyk Gateway, you need to use Redis.

A free, open source, Redis install is all that’s required.


@Yauhen_Savionak A similar topic was discussed here Is REDIS mandatory? - #12 by Jonathan_Gurwitz

My main concern was more around what would fail if redis went down.

  • The Global rate limiter shares data between instances so, if it is enabled, I would want to know what happens if redis fails

  • The Distributed Rate Limiter is local to the instance so how is this impacted by a redis failure? Does DRL store data in REDIS? (I couldn’t find documentation on how to configure DRL. Only GRL)

Hi @Jonathan_Gurwitz - thanks for clarifying. We can certainly describe various Resilience and DR scenarios. A few questions, so folks can better advise in this scenario:

  1. Are you deploying Tyk Gateways in a headless config, or are you coupling them with a dashboard/control plane?
  2. If you are using dash or control plane, would that be either self-managed or saas?
  3. How many gateways will be in the cluster where Redis fails?
  4. Are there other clusters, with a separate, Redis deployment that is still active?
  5. In this scenario is the Redis failure one of connectivity, where it is then restored at a later time/date, or is the scenario that Redis burns and is irrecoverable?

Thanks for the extra context here if possible, it will help guide responses

Hi @James

  1. we use headless config
  2. we don’t use sash or control plane. our target is maximum light Tyk GW
  3. By default we plan 1 GW per service. But need test. Possible will ne scale it, ideally auto-scaling in K8S
    4.at this moment we are looking for possibility deploy without Redis.
  4. General idea maximum light of GW without Redis. Still Open question about case with some clusters in this case. But this is next step