Chykalophia Docs

What Redis is used for in an application, how access and connection strings work, and why it should never be your only copy of anything.

Redis is an in-memory data store used for the fast, temporary things an application needs: caching, session storage, rate limiting, and job queues. Because it keeps data in memory rather than on disk, it is much faster than a database — and correspondingly less durable.

One naming note before you go looking for it in a provider's console: not every host still calls this "Redis". Render, for example, sells it as Key Value, and new instances there run Valkey, an open-source fork of Redis. Everything below applies to those offerings too, and ordinary Redis clients connect to them unchanged.

Quick summary

Access is a connection URL with a password, held in environment variables. Redis is a supporting store, not a system of record — anything in it should be reconstructable from PostgreSQL or another durable source. Never expose an instance to the internet without a password — Redis is built for trusted clients on a trusted network, and an open instance is a serious security problem.

What it's typically used for

Use	Why Redis	If it's lost
Caching	Avoids repeating expensive queries	Slower until the cache refills
Sessions	Fast lookup on every request	Users are logged out
Rate limiting	Cheap counters with expiry	Limits reset
Job queues	Fast push/pop for background work	Queued jobs may be lost

Note the last row. If job queues matter — payment processing, email sending — the queue needs persistence enabled and the jobs need to be idempotent, so a retry doesn't charge someone twice.

Access

A connection URL, much like Postgres:

rediss://default:password@host:6379

The rediss:// scheme (double s) means TLS. Use it for anything crossing a network you don't control.

Never expose Redis without authentication

Redis's own guidance is that it is designed to be accessed by trusted clients inside trusted environments, and its default user historically required no password at all. The risk isn't only your data: because a connected client can change the server's configuration, Redis documents this as a route to writing files to arbitrary paths and running untrusted code on the machine. Always require a password, always prefer TLS, and keep the instance on a private network reachable only by your own services. Since version 3.2 Redis also has a protected mode that refuses non-local connections when it is running with the default configuration and no password — useful, but not a substitute for configuring it properly.

Redis 6 was the first version with ACLs — separate users with restricted command sets, so a service that only reads a cache cannot issue FLUSHALL. Managed providers vary in whether they expose this.

Memory and eviction

Redis holds everything in memory, so it has a hard ceiling. What happens when it fills up is a configuration choice:

Eviction policies discard existing keys to make room — usually the least recently or least frequently used ones. Correct for a pure cache.
No eviction (noeviction) makes the server return an error on any command that would store new data, while reads keep working. Correct for a queue, where silently dropping data would be worse.

Getting this wrong is a classic incident: a queue configured with a cache eviction policy quietly discards jobs under load.

Persistence

Managed Redis can be configured to write to disk, so a restart doesn't lose everything. Redis offers point-in-time snapshots taken at intervals, an append-only log of every write, or both. Either way this reduces data loss rather than eliminating it: with snapshots alone, Redis's own docs say to expect to lose the last few minutes of writes after an unclean stop. Free tiers of managed Redis often don't persist to disk at all. Design on the assumption that Redis can be empty at any moment.

Common questions

Do we need Redis at all?

Not always. It earns its place when the same expensive query runs repeatedly, when sessions must be shared across multiple servers, or when background jobs need a queue. A small single-server application usually doesn't need it — adding it introduces another service to secure and monitor.

Users keep getting logged out. Is that Redis?

Often, yes — if sessions are stored in Redis and it restarted, hit its memory limit, or evicted session keys. Check whether the eviction policy is discarding session data, and whether the instance is sized correctly.

Is data in Redis encrypted?

In transit, if you use TLS. At rest, it depends on the provider — many managed offerings encrypt persisted snapshots. Avoid storing sensitive personal data in Redis regardless; it belongs in a durable, properly encrypted store.

Can we clear the cache safely?

Usually yes — a cache is by definition reconstructable, and clearing it causes a temporary slowdown while it refills. But if the same instance also holds sessions or queues, a blanket flush logs everyone out and destroys pending jobs. Confirm what's stored before flushing anything.

Need a hand?

If you're stuck, email support@chykalophia.com and we'll help. Include your website address and a screenshot if you can.

Managed Redis access