Redis · 7
Managed Redis 7
An in-memory database for what your application should neither recompute nor keep on disk: response cache, user sessions, work queues and counters. It comes up from the dashboard with the password and certificates ready, and connections require TLS with a client certificate on a port unique to that database.
Redis began as a solution to a real problem
Salvatore Sanfilippo created the project in 2009 to solve data-access challenges at his startup; the community turned it into a core building block for real-time applications.
Salvatore Sanfilippo
dotconferences · CC BY 3.0
2009: a focused project
Redis began as a direct response to data-handling problems, without trying to be a general platform from day one.
Memory and data structures
The idea combined fast in-memory access with useful structures such as strings, lists, sets, and hashes.
From project to community
Usage grew beyond the original case, and open development established Redis as a simple tool for caching, queues, and real-time state.
What comes with a Redis here
None of this is something you configure: it is the default behavior of every Redis created on the platform.
Password, TLS and client certificate required
The instance requires a password and refuses cleartext connections. The CA, server certificate and client certificate are generated at creation time and stay available for download in the dashboard or through the API.
Keys and TTLs in the panel
The Data tab walks keys with SCAN in pages of 200, shows the value according to its type (string, list, set, zset, hash, stream) and the TTL of each one. A collection with more than 1000 items comes back marked as truncated.
No arbitrary commands, on purpose
The Data tab runs no free-form command: KEYS, FLUSHALL, FLUSHDB, CONFIG, DEBUG, SCRIPT and EVAL do not go through. It is there to inspect and fix a key, not to operate the server from a browser.
Snapshots with download and restore
Manual snapshots of the volume, restore from any earlier snapshot (with a 30-second cooldown) and download of the contents as a ZIP. Available from the Scale plan up.
Where Redis fits in your application
It is almost never the primary database: it sits in front of one, or between two processes.
Query and response caching
Store the expensive result — the heavy query, the third-party API call, the already-rendered HTML — with a TTL. The relational database stops answering the same question several times a minute.
Sessions and login state
Sessions living outside the application process: restarting the container or applying a patch logs nobody out, because the state is not in the app's memory.
Work queues between processes
One application publishes the work, another consumes it — sending email, processing images, retrying webhooks. The two containers talk over the database's internal host, with TLS.
Counters, rate limits and cooldowns
Atomic increments and keys with expiry cover per-user request limits and bot command cooldowns without a table and a cleanup job.
Connection details
The host follows the format id-without-hyphens.db.usa1.vertraweb.app and the port is unique to each database. Authentication is a password over TLS with a client certificate — the password and certificates live in the database credentials tab.
| Version | 7 |
|---|---|
| Port | <port> |
| TLS | Required |
| Authentication | Certificate + password |
| Host | <id>.db.usa1.vertraweb.app |
Connecting with redis-cli
--tls, --cacert and --cert/--key with the dashboard's certificates are all required — without the client certificate the connection is refused even with the right password. Keep the password in an environment variable: passed literally, it ends up in your shell history.
redis-cli -h <id>.db.usa1.vertraweb.app -p <port> -a "$SENHA" --tls --cacert certificate.pem --cert certificate.crt --key certificate.keyA plan for every stage of the project
Memory and storage change with the plan; the engine does not. Compare the plans and pick the one that fits today.
Compare plansOther managed databases
Same dashboard, same certificates, a different engine.
Frequently asked questions about managed Redis
The questions support sees most often, answered short.
How do I connect my application over TLS?
Turn TLS on in the client and point the CA and the client certificate at the database's files, together with the password — in redis-cli that is --tls --cacert certificate.pem --cert certificate.crt --key certificate.key -a; in a library, it is the same three TLS options. Connections without TLS or without a client certificate are not accepted.
Where do I download the certificate and the password?
On the database page in the dashboard, next to the credentials, or through the API. The CA, server certificate and client certificate are generated automatically at creation; Reset Password and Reset Certificates rotate each of them.
Does restarting the database erase my keys?
No. Restarting brings the same instance back up, with the same volume. What erases the contents is the Reset operation, flagged as destructive: it returns the database to the state of a freshly created instance. Even so, treat Redis as data you know how to rebuild.
How do I restore a snapshot?
From the database's snapshots tab, picking the point you want to return to. There is a 30-second cooldown between restores, and the contents can also be downloaded as a ZIP. Manual snapshots are available from the Scale plan up.
Which plan do I need?
You need a plan with enough free RAM to allocate to the database. This Redis instance requires at least 512 MB, and the number of databases on paid plans depends on available memory, not a fixed quota. Free ("suspended") allows 1 app + 1 database, but the Free plan's RAM is still pending definition. To browse keys through the Data tab, the database owner's plan must be Intermediary or higher.
Create your managed Redis
Pick the RAM, wait for the instance to come up and connect with the password and certificate from the dashboard. The cache is ready before you finish configuring the client.
Create account