Luceris Cloud

Solutions · Sessions & cache

Sessions that stay fast under load.

Per-tenant Redis on Luceris is the right storage for session state and HTTP caching — sub-millisecond reads, durable enough for sessions, and isolated from your noisy-neighbor concerns.

Start freeTalk to us

Two patterns, one cluster

Session storage and HTTP caching look similar from outside but behave differently in production. Sessions are durable (you do not want users logged out on a restart), low-volume, and read-heavy. HTTP caches are ephemeral (eviction is by design), high-volume, and read-heavy. On a single Luceris Redis cluster you can run both — pick the right persistence and eviction settings per database, or run two clusters if you want hard isolation.

AOF persistence for sessions

Append-only file with fsync every second (or every write on request). Sessions survive Redis restarts without users having to reauthenticate.

LRU / LFU eviction for caches

`allkeys-lru` for general HTTP caches; `volatile-ttl` for caches with explicit expirations. Set per cluster, change without downtime.

TLS-only ingress

No plaintext connections. Per-tenant credentials validated at the proxy. Optional IP allowlists on the Contact-us tier.

No noisy neighbors

Dedicated `redis-server` per tenant. A spike in your traffic stays in your cluster — no shared-cluster latency bumps from other customers.

Code sample

js
Express session middleware backed by Luceris Redis
import express from 'express';
import session from 'express-session';
import { RedisStore } from 'connect-redis';
import { createClient } from 'redis';

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

const app = express();
app.use(session({
  store: new RedisStore({ client: redis, prefix: 'sess:' }),
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: { secure: true, httpOnly: true, sameSite: 'lax', maxAge: 60 * 60 * 24 * 30 * 1000 },
}));

app.get('/', (req, res) => {
  req.session.views = (req.session.views || 0) + 1;
  res.send(`Views: ${req.session.views}`);
});

Sizing

A typical web session is 1–5 KB. The Free tier (256 MB) holds ~50,000 active sessions. For HTTP caching, the working-set size matters more than memory — measure your hit rate at different cluster sizes and pick the one that gives you the latency you need.

Examples

  • Express / Fastify / Koa session middleware
  • NextAuth session adapter for Redis
  • CDN-style HTTP cache in front of a slower API
  • Per-user permission cache (cached for 60s; invalidated on role change)
  • Idempotency-key store for retried POST requests

Frequently asked questions

Will I lose sessions on restart?
No, as long as the cluster has AOF persistence enabled (the default). RDB-only clusters can lose the last few seconds of writes; pure-cache clusters lose everything by design.
How do I handle session-fixation rotation?
Use your framework's session-regeneration API at login — it deletes the old key and writes a new one. On Redis we recommend setting a max-age of 30 days as a backstop.
Should I run sessions and HTTP cache on the same cluster?
On the Free tier, yes — separate them by key prefix and let LRU eviction run. On larger workloads, run separate clusters so the eviction policy can be tuned per workload.

Hot path, cold storage, and the difference clearly drawn.

256 MB free Redis with AOF persistence — enough for tens of thousands of sessions.

Start freeTalk to us