← RenderCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Render
Snapshot Sep 30, 2026 · 22:43 UTC · version 1.0.1
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "render-keyvalue",
"description": "Provisions and configures Render Key Value (Redis-compatible Valkey 8) instances for caching, session storage, and job queues. Use when the user needs Redis, Key Value, Valkey, a cache, session store, job queue backend, or needs to configure maxmemory policy, ipAllowList, connection strings, or internal vs external access. Trigger terms: Key Value, Redis, Valkey, cache, session store, REDIS_URL, maxmemory, ipAllowList, allkeys-lru, noeviction.",
"included_files": [
{
"relative_path": "references/connection-examples.md",
"size_in_bytes": 2239
},
{
"relative_path": "references/troubleshooting.md",
"size_in_bytes": 2747
}
],
"skill_md_contents": "---\nname: render-keyvalue\ndescription: >-\n Provisions and configures Render Key Value (Redis-compatible Valkey 8)\n instances for caching, session storage, and job queues. Use when the user\n needs Redis, Key Value, Valkey, a cache, session store, job queue backend,\n or needs to configure maxmemory policy, ipAllowList, connection strings,\n or internal vs external access.\n Trigger terms: Key Value, Redis, Valkey, cache, session store, REDIS_URL,\n maxmemory, ipAllowList, allkeys-lru, noeviction.\nlicense: MIT\ncompatibility: Render Key Value instances (free and paid plans)\nmetadata:\n author: Render\n version: \"1.0.0\"\n category: data\n---\n\n# Render Key Value\n\nRender 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.\n\n## When to Use\n\n- Adding a **cache** or **session store** to a web app\n- Wiring a **job queue** backend for Celery, Sidekiq, BullMQ, Asynq, or Oban\n- Choosing the right **maxmemory policy** (cache vs queue)\n- Configuring **ipAllowList** in Blueprints (required field)\n- Connecting via **internal vs external URLs**\n- Troubleshooting **auth failures** or **connection refused** errors\n\nFor background worker setup and queue framework patterns, see **render-background-workers**. For Blueprint authoring, see **render-blueprints**.\n\n## Key Concepts\n\n### Valkey 8 (not Redis)\n\nNew 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.\n\n### Connection URLs\n\nEvery instance has two URLs:\n\n| URL type | When to use | Auth required |\n|----------|-------------|---------------|\n| **Internal** (`redis://red-xxx:6379`) | From Render services in the same region | No (by default) |\n| **External** (`rediss://red-xxx:6379`) | From outside Render (local dev, CI) | Always |\n\n**Always prefer the internal URL** for production services—lower latency, no TLS overhead, communicates over the private network.\n\nExternal connections are **disabled by default**. Enable them by adding IP ranges to the access control list in the Dashboard.\n\n### Internal authentication\n\nBy 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:\n\n```\nredis://default:PASSWORD@red-xxx:6379\n```\n\n**Warning:** Enabling internal auth breaks existing unauthenticated connections. Migrate clients to the authenticated URL first.\n\n## Maxmemory Policy\n\n**Critical decision.** Choose based on your use case:\n\n| Use case | Policy | Why |\n|----------|--------|-----|\n| **Cache** (can lose data) | `allkeys-lru` | Evicts least-recently-used keys to free space |\n| **Job queue** (cannot lose data) | `noeviction` | Returns error on writes when full; never drops keys |\n| **Session store** | `allkeys-lru` or `volatile-lru` | Sessions can be regenerated; LRU is safe |\n\nAll available policies:\n\n| Policy | Behavior | Memory fills up? |\n|--------|----------|-----------------|\n| `allkeys-lru` | Evict any key by LRU | No |\n| `noeviction` | Error on writes when full | Yes |\n| `volatile-lru` | Evict keys with TTL by LRU | Yes |\n| `volatile-lfu` | Evict keys with TTL by LFU | Yes |\n| `allkeys-lfu` | Evict any key by LFU | No |\n| `volatile-random` | Evict random keys with TTL | Yes |\n| `allkeys-random` | Evict any random key | No |\n| `volatile-ttl` | Evict keys nearest to expiry | Yes |\n\n## Blueprint Configuration\n\n```yaml\nservices:\n - type: keyvalue\n name: cache\n plan: starter\n region: oregon\n maxmemoryPolicy: allkeys-lru\n ipAllowList: []\n```\n\n### `ipAllowList` is required\n\nBlueprints **must** include `ipAllowList` on Key Value services. Common patterns:\n\n| Value | Meaning |\n|-------|---------|\n| `[]` | No external access (internal only—**recommended for most apps**) |\n| `[{source: \"0.0.0.0/0\", description: \"everywhere\"}]` | Open external access (use sparingly) |\n| `[{source: \"203.0.113.0/24\", description: \"office\"}]` | Specific IP ranges |\n\n### Wiring to services\n\nUse `fromService` with `type: keyvalue` and `property: connectionString`:\n\n```yaml\nenvVars:\n - key: REDIS_URL\n fromService:\n name: cache\n type: keyvalue\n property: connectionString\n```\n\nAvailable `fromService` properties for Key Value:\n\n| Property | Value |\n|----------|-------|\n| `connectionString` | Full internal URL (`redis://red-xxx:6379`) |\n| `host` | Hostname only |\n| `port` | Port only (typically `6379`) |\n\n## Data Persistence\n\n- **Paid instances:** Disk-backed, `appendfsync everysec`. You may lose up to 1 second of writes on interruption.\n- **Free instances:** No disk persistence. Data is lost on restart or upgrade.\n- **Upgrading from Free:** All data is lost during the upgrade because Free instances have no disk.\n\n## Instance Types and Upgrades\n\n- Instance type determines **RAM** and **connection limit**\n- You can **upgrade** to a larger type (brief downtime, ~1-2 minutes)\n- You **cannot downgrade** to a smaller type\n- For instances larger than 10 GB RAM, contact Render support\n\n## Connection Examples\n\nSee `references/connection-examples.md` for client code in Node.js (ioredis, node-redis), Python (redis-py), Ruby (redis-rb, Sidekiq), and Go.\n\n## Common Mistakes\n\n| Mistake | Fix |\n|---------|-----|\n| Missing `ipAllowList` in Blueprint | Add `ipAllowList: []` for internal-only access |\n| Using `allkeys-lru` for job queues | Switch to `noeviction`—LRU eviction drops queued jobs |\n| Connecting with external URL from a Render service | Use the internal URL for lower latency and no auth requirement |\n| Forgetting `type: keyvalue` in `fromService` | `type` is required; without it the wiring fails |\n| Using deprecated `redis` type alias | Prefer `keyvalue` in new Blueprints (`redis` still works but is deprecated) |\n\n## References\n\n| Document | Contents |\n|----------|----------|\n| `references/connection-examples.md` | Client code for Node.js, Python, Ruby, Go |\n| `references/troubleshooting.md` | Auth errors, connection refused, memory full, migration from Redis 6 |\n\n## Related Skills\n\n- **render-background-workers** — Queue consumer setup with Celery, Sidekiq, BullMQ\n- **render-blueprints** — Full `render.yaml` schema, `fromService` patterns\n- **render-networking** — Private network, internal URLs\n- **render-env-vars** — Wiring `REDIS_URL` and other connection vars\n"
}SHA-256: 4145272d61292da5dbe53313ecf23ba012703220a294afc8363819b9d1bf5eb9