cookbook / redis
Redis
A Redis server (Valkey-compatible) for caches and queues.
- cache
- queue
Run it
briq_run({
recipe: "redis",
params: {
"version": "7",
"size": "nano"
},
wait: true
})briq run redis
briq ls
briq logs -f <id>
briq rm <id>import { Briq } from '@briq/sdk';
const briq = new Briq(process.env.BRIQ_API_KEY);
const redis = await briq.run({
recipe: 'redis',
params: {
"version": "7",
"size": "nano"
},
});
console.log(redis.outputs.REDIS_URL);
// ... when done
await briq.destroy(redis.id);Parameters
| Name | Type | Options | Default |
|---|---|---|---|
| version | enum | 7 | "7" |
| size | enum | nano, small, medium, large | "nano" |
Outputs
Returned by briq_run once the stack is healthy. Hosts resolve inside your team network; secrets are generated per run.
- REDIS_URL
- redis://redis.<stack>.internal:6379
What it runs
| Briq | Image | Ports | Size | Volume |
|---|---|---|---|---|
| redis | redis:7-alpine | 6379 | nano | — |
When to use it
- Your app or worker expects
REDIS_URLfor caching, sessions, rate limiting or a queue. - You are testing BullMQ, Sidekiq-style or Celery-style workers and need a real broker that behaves like production.
- The agent needs a scratch key-value store for a job it is running.
The recipe runs redis:7-alpine on a nano briq by default, which is enough for most test loads.
There is no persistent volume: data lives as long as the briq runs. Move to small if you push
more than a few hundred MB.
Tips
- No password by default. The briq is only reachable inside your team network, at
redis.<stack>.internal:6379. Do not expose it publicly. - Pair it with the app under test in one stack.
stack: "checkout"for both, then the app usesREDIS_URLfrom the outputs. - Inspect it with the CLI image.
briq_execwith["redis-cli", "info", "memory"]or["redis-cli", "monitor"]for a few seconds of traffic. - Queues in v1. The
redis-bullmqrecipe will bundle Redis, a Bull Board UI and a worker skeleton the agent can fill in.