Fix Redis connection and memory errors

Find your error below. Before digging in, check that the instance shows Running on its Overview tab.

NOAUTH Authentication required

(error) NOAUTH Authentication required.

The connection opened but the client never sent a password. Common causes:

• The client got a host and port but no URL, so the password never reached it. Pass the full URL from the Overview tab, for example Redis.from_url(os.environ["REDIS_URL"]) in redis-py or new Redis(process.env.REDIS_URL) in ioredis.
• redis-cli -h host -p 6379 without -a. Use redis-cli -u "<url>" instead.
• The REDIS_URL environment variable is empty in the environment where the code actually runs. Check the service’s Environment tab and restart after changing it.

WRONGPASS invalid username-password pair

(error) WRONGPASS invalid username-password pair or user is disabled.

The password is wrong. Click the eye icon on the Overview tab and compare it with what your app has. Watch for a trailing newline or quotes picked up from a .env file.

The URL has an empty username (rediss://:password@host), which means the default user. If your client insists on a username, use default.

The password can’t be changed from the dashboard. If it leaked, create a new instance and switch your app to it.

redis-cli can’t connect over TLS

The external URL starts with rediss://, two s, and accepts TLS connections only. With plain redis:// against the external host, the connection resets or hangs.

redis-cli -u "rediss://:password@red-xxxxxxxxxxxx-a.eu-central-redis.runsite.app" PING

If that fails:

• Your redis-cli was built without TLS. Run redis-cli --help | grep tls. If nothing shows up, install a newer build. Homebrew and the official Redis and Valkey packages include TLS.
• The client doesn’t send the hostname (SNI). The proxy routes TLS connections by hostname, so a connection without SNI is dropped. Add it explicitly: redis-cli --tls --sni red-xxxxxxxxxxxx-a.eu-central-redis.runsite.app -u "rediss://...".
• External connections are turned off. Check Settings → Public access. With Allow external connections off, only services in the same workspace can reach the instance, over the internal redis:// URL.

From another Runsite service, skip all of this and use the internal URL. It needs no TLS.

The instance restarts when memory fills up

Managed Redis doesn’t evict keys on its own. There’s no maxmemory limit inside Redis, so the dataset keeps growing until it reaches the plan’s memory limit. At that point the container is killed and restarted. On a persistent plan, Redis reloads what it last saved to disk. On a cache plan, the data is gone.

You’ll see it coming on the Metrics tab, where memory climbs toward the plan limit. To check from a client:

redis-cli -u "$REDIS_URL" INFO memory | grep used_memory_human

Ways to keep it under control:

• Set a TTL on everything that is a cache. SET key value EX 3600 expires the key after an hour. Keys without a TTL live forever.

• Let Redis evict for you. Set a limit a bit below the plan’s memory and an eviction policy:

  redis-cli -u "$REDIS_URL" CONFIG SET maxmemory 200mb
  redis-cli -u "$REDIS_URL" CONFIG SET maxmemory-policy allkeys-lru

  allkeys-lru drops the least recently used keys, which is right for a pure cache. volatile-lru only drops keys that have a TTL, which is safer when the same instance holds sessions or queues. Settings made with CONFIG SET are lost when the instance restarts, so run them again from your app on startup.

• Move to a bigger plan in Settings → Plan. Paid plans can switch between each other; a short restart applies the new limit.

Once maxmemory is set with the default noeviction policy, writes fail with OOM command not allowed when used memory > 'maxmemory' instead of the instance restarting. That error means you set a limit without an eviction policy.

Still stuck

The Logs tab shows what the server saw, including restarts and rejected connections. The dashboard page describes each tab, and Connecting to Redis covers the URL formats.