Key-value store
A key-value store is the fast, in-memory place your services reach for when a database would be overkill. Cached responses, user sessions, rate-limit counters, a queue for background jobs.
Lucity gives you a Redis®-compatible store, so every Redis client and library you already use works against it unchanged.
Provisioning
On the project canvas, click Create and choose Redis. Give it a name between 2 and 16 characters and confirm.
A store belongs to one environment, so development and production each get their own with separate data and separate passwords.
Connect
Connect a service with a dynamic variable. Open the service's Variables tab, click the link icon in the value field, and pick from the store's group. It exposes four values:
| Variable | What it is |
|---|---|
uri | The complete connection URL, which is usually the only one you need |
host | The private hostname |
port | 6379 |
password | The generated password |
Most libraries take the URL directly, so linking uri to REDIS_URL is usually the whole job.
The store's Connect tab shows the same values if you need to read them. The store is reachable only from services in its own environment and there is no built-in way to expose it to the internet.
What it is good for
- Caching. Expensive query results, rendered fragments, and responses from APIs that are slower than you would like.
- Sessions. Anything held in a service's memory belongs to one instance and disappears when it rolls. A session store here survives deploys and works across replicas.
- Rate limiting and counters. Atomic increments with expiry, which is exactly what the data structures are for.
- Job queues. BullMQ, Sidekiq, Celery, RQ and the rest all run on a Redis-compatible store. Point the worker and the producer at the same one.
Persistence
Writes are appended to disk as they happen, so the data survives a restart or a redeploy. Treat it as durable enough for sessions and queues, and not as the place for anything you cannot lose. It is a single instance with no replica and no backups, so a lost store is a lost store. Anything you would be upset to lose belongs in PostgreSQL.
Each store gets 1 GB of disk. Set your expiries and your eviction accordingly, and remember that a queue with no consumer keeps growing.
Under the hood
Stores run Valkey(opens in a new tab), the open-source fork of Redis, as a single instance with append-only persistence and password authentication. The Redis protocol is the interface, which is why your existing clients neither know nor care about the difference. An ejected project keeps the store as a plain StatefulSet.
Next steps
- Variables for wiring a store into a service
- PostgreSQL for data that has to survive
- Services for why shared state matters once you run more than one instance