What you get

Per project: a managed Redis instance, with credentials injected as REDIS_URL:

REDIS_URL=redis://default:pass@host:port/0

Standard Redis clients work without modification:

import { createClient } from "redis"
const redis = createClient({ url: process.env.REDIS_URL })
await redis.connect()

await redis.set("user:123:last-seen", new Date().toISOString())
const value = await redis.get("user:123:last-seen")

Use cases

• Cache — short-lived computed results.
• Sessions — express-session / Phoenix sessions / similar.
• Pub/sub — agent coordination, real-time fan-out.
• Rate limiting — atomic INCR + TTL.
• Job queues — Bull, BullMQ, Sidekiq, Oban-light alternatives.

For full job-queue workloads at scale, MIOSA has a Background Jobs primitive that’s a better fit than rolling your own on Redis.

Provision

await miosa.projects.dataServices.create(projectId, {
  type: "redis",
  size: "small",  // small | medium | large
})

Limits

The small tier treats Redis as ephemeral — appropriate for cache, not for sessions you want to survive a restart. Bump to medium for session storage.

Pub/sub considerations

If you’re using Redis pub/sub for cross-runtime coordination, multiple runtime instances of the same service can all subscribe — MIOSA does not deduplicate or proxy pub/sub. For higher-volume real-time fan-out, consider SSE through MIOSA’s Events or a dedicated message broker.

Bring your own Redis?

Yes. Set REDIS_URL as an env var to whatever external Redis you prefer (Upstash, AWS ElastiCache, your own).

See also

• Overview — the broader data plane
• Runtime Instances — for background-job workloads