Key-value store

The Appentic key-value store is a Redis-compatible managed service. It speaks the Redis wire protocol, so any existing Redis client library (ioredis, redis-py, go-redis, lettuce) works without modification. You drop it in where you'd normally use Redis, and the client library won't know or care that it's on Appentic.

Creating a store

From your project dashboard, click New resource, then Key-value store. Pick a size, pick a region (usually the same region as the services that will read from it), and click Create. Provisioning takes a few seconds.

Connecting

Services in the same project receive:

• REDIS_URL in standard redis://user:password@host:port form, which every mainstream Redis client accepts directly.
• REDIS_HOST, REDIS_PORT, REDIS_PASSWORD as individual components if you need them separately.

In Node.js with ioredis:

import Redis from 'ioredis'
const redis = new Redis(process.env.REDIS_URL)

In Python with redis-py:

import redis
r = redis.from_url(os.environ['REDIS_URL'])

In Go with go-redis:

opt, _ := redis.ParseURL(os.Getenv("REDIS_URL"))
rdb := redis.NewClient(opt)

There's no connection pool to configure by hand beyond whatever your client library recommends for its own defaults.

Persistence

Stores are memory-first with periodic snapshots to disk. They survive restarts and planned maintenance, but they're not durable in the strict database sense: if you need a value to never be lost, put it in PostgreSQL and use the key-value store as a cache on top.

Good uses

• Response and query caching. Cache expensive database queries or upstream API responses for a few minutes.
• Session storage. Fast session lookups for web apps, keyed on session ID.
• Rate limiting. Sliding-window counters for API rate limits.
• Pub/sub. Lightweight message passing between services and workers.
• Short-lived state. Feature flags, A/B test assignments, in-flight job locks.

Related

• PostgreSQL
• Workers