render-keyvalue
Render Key Value
Render Key Value provides low-latency, Redis-compatible in-memory storage running Valkey 8. Use it as a shared cache, session store, or job queue backend. Compatible with virtually all Redis client libraries.
When to Use
- Adding a cache or session store to a web app
- Wiring a job queue backend for Celery, Sidekiq, BullMQ, Asynq, or Oban
- Choosing the right maxmemory policy (cache vs queue)
- Configuring ipAllowList in Blueprints (required field)
- Connecting via internal vs external URLs
- Troubleshooting auth failures or connection refused errors
For background worker setup and queue framework patterns, see render-background-workers. For Blueprint authoring, see render-blueprints.
Key Concepts
Valkey 8 (not Redis)
New instances run Valkey 8, an open-source Redis fork. It is a drop-in replacement for Redis—existing Redis client libraries work without changes. Legacy instances (created before Feb 2025) run Redis 6.
Connection URLs
Every instance has two URLs:
| URL type | When to use | Auth required |
|---|---|---|
Internal (redis://red-xxx:6379) |
From Render services in the same region | No (by default) |
External (rediss://red-xxx:6379) |
From outside Render (local dev, CI) | Always |
Always prefer the internal URL for production services—lower latency, no TLS overhead, communicates over the private network.
External connections are disabled by default. Enable them by adding IP ranges to the access control list in the Dashboard.
Internal authentication
By default, internal connections are unauthenticated. You can require auth for internal connections in the Dashboard for compliance or extra security. This changes the internal URL to include credentials:
redis://default:PASSWORD@red-xxx:6379
Warning: Enabling internal auth breaks existing unauthenticated connections. Migrate clients to the authenticated URL first.
Maxmemory Policy
Critical decision. Choose based on your use case:
| Use case | Policy | Why |
|---|---|---|
| Cache (can lose data) | allkeys-lru |
Evicts least-recently-used keys to free space |
| Job queue (cannot lose data) | noeviction |
Returns error on writes when full; never drops keys |
| Session store | allkeys-lru or volatile-lru |
Sessions can be regenerated; LRU is safe |
All available policies:
| Policy | Behavior | Memory fills up? |
|---|---|---|
allkeys-lru |
Evict any key by LRU | No |
noeviction |
Error on writes when full | Yes |
volatile-lru |
Evict keys with TTL by LRU | Yes |
volatile-lfu |
Evict keys with TTL by LFU | Yes |
allkeys-lfu |
Evict any key by LFU | No |
volatile-random |
Evict random keys with TTL | Yes |
allkeys-random |
Evict any random key | No |
volatile-ttl |
Evict keys nearest to expiry | Yes |
Blueprint Configuration
services:
- type: keyvalue
name: cache
plan: starter
region: oregon
maxmemoryPolicy: allkeys-lru
ipAllowList: []
ipAllowList is required
Blueprints must include ipAllowList on Key Value services. Common patterns:
| Value | Meaning |
|---|---|
[] |
No external access (internal only—recommended for most apps) |
[{source: "0.0.0.0/0", description: "everywhere"}] |
Open external access (use sparingly) |
[{source: "203.0.113.0/24", description: "office"}] |
Specific IP ranges |
Wiring to services
Use fromService with type: keyvalue and property: connectionString:
envVars:
- key: REDIS_URL
fromService:
name: cache
type: keyvalue
property: connectionString
Available fromService properties for Key Value:
| Property | Value |
|---|---|
connectionString |
Full internal URL (redis://red-xxx:6379) |
host |
Hostname only |
port |
Port only (typically 6379) |
Data Persistence
- Paid instances: Disk-backed,
appendfsync everysec. You may lose up to 1 second of writes on interruption. - Free instances: No disk persistence. Data is lost on restart or upgrade.
- Upgrading from Free: All data is lost during the upgrade because Free instances have no disk.
Instance Types and Upgrades
- Instance type determines RAM and connection limit
- You can upgrade to a larger type (brief downtime, ~1-2 minutes)
- You cannot downgrade to a smaller type
- For instances larger than 10 GB RAM, contact Render support
Connection Examples
See references/connection-examples.md for client code in Node.js (ioredis, node-redis), Python (redis-py), Ruby (redis-rb, Sidekiq), and Go.
Common Mistakes
| Mistake | Fix |
|---|---|
Missing ipAllowList in Blueprint |
Add ipAllowList: [] for internal-only access |
Using allkeys-lru for job queues |
Switch to noeviction—LRU eviction drops queued jobs |
| Connecting with external URL from a Render service | Use the internal URL for lower latency and no auth requirement |
Forgetting type: keyvalue in fromService |
type is required; without it the wiring fails |
Using deprecated redis type alias |
Prefer keyvalue in new Blueprints (redis still works but is deprecated) |
References
| Document | Contents |
|---|---|
references/connection-examples.md |
Client code for Node.js, Python, Ruby, Go |
references/troubleshooting.md |
Auth errors, connection refused, memory full, migration from Redis 6 |
Related Skills
- render-background-workers — Queue consumer setup with Celery, Sidekiq, BullMQ
- render-blueprints — Full
render.yamlschema,fromServicepatterns - render-networking — Private network, internal URLs
- render-env-vars — Wiring
REDIS_URLand other connection vars
More from render-oss/skills
render-deploy
Deploy applications to Render by analyzing codebases, generating render.yaml Blueprints, and providing Dashboard deeplinks. Use when the user wants to deploy, host, publish, or set up their application on Render's cloud platform.
58render-debug
Debug failed Render deployments by analyzing logs, metrics, and database state. Identifies errors (missing env vars, port binding, OOM, etc.) and suggests fixes. Use when deployments fail, services won't start, or users mention errors, logs, or debugging.
46render-monitor
Monitor Render services in real-time. Check health, performance metrics, logs, and resource usage. Use when users want to check service status, view metrics, monitor performance, or verify deployments are healthy.
45render-workflows
Sets up, develops, tests, and deploys Render Workflows. Covers first-time scaffolding (via CLI or manual), SDK installation (Python or TypeScript), task patterns (retries, subtasks, fan-out), local development, Dashboard deployment, and troubleshooting. Use when a user wants to set up Render Workflows for the first time, scaffold a workflow service, add or modify workflow tasks, test workflows locally, or deploy workflows to Render.
34render-migrate-from-heroku
Migrate from Heroku to Render by reading local project files and generating equivalent Render services. Triggers: any mention of migrating from Heroku, moving off Heroku, Heroku to Render migration, or switching from Heroku. Reads Procfile, dependency files, and app config from the local repo. Optionally uses Heroku MCP to enrich with live config vars, add-on details, and dyno sizes. Uses Render MCP or Blueprint YAML to create services.
27render-networking
>-
13