Caching with Redis

Run Redis as its own Falix server, then cache from your app — cooldowns, rate limits, and sessions with self-expiring keys — plus the honest rule about what never to keep there.

Redis is an in-memory key/value store — extremely fast, and perfect for data that's allowed to be temporary: cooldowns, rate limits, session tokens, cached results. On Falix you run Redis as its own server, then connect to it from your app. This guide does both halves and, just as importantly, tells you what not to keep there.

At a glance
You need An app (a bot or web app) that would benefit from caching, plus a second server to run Redis on
Plan Any
Helps to know Run your own database server — its trade-offs apply directly here

Half one: run the Redis server

Redis is one of Falix's database applications. Create a server for it (or switch a spare server's application in Settings — switching reinstalls and wipes files, so use a fresh one) and pick the Redis 7 application. At install:

  • Redis binds your server's single public port (SERVER_PORT) automatically.
  • A password is generated into the Redis Password variable — read it under Settings → variables.
  • You reach it from outside at the server's public address and port, shown on the Network page.

⚠️ Heads up: Redis is only useful while it's running, and a Redis server obeys the same rules as any other. On a free plan it stops when the session timer runs out, and the moment it does, everything caching to it starts throwing connection errors. If real traffic depends on the cache, run Redis on a server you keep online — realistically a premium plan that runs 24/7. See Keeping apps online.

💡 Tip: If the app that uses Redis is another of your Falix servers, you don't have to expose Redis publicly at all.

The Network page's Internal Network gives each server a private uuid.internal address reachable from your other servers; point your app at that internal address and the app and its cache talk privately, with nothing extra open to the world.

Half two: use it from Node

Install the redis package from the Packages page (search redis, install, restart). Keep the connection details in .env — host and port are the Redis server's public (or internal) address, and the password is its Redis Password value:

REDIS_HOST=your-redis-address
REDIS_PORT=12345
REDIS_PASSWORD=the-generated-password

Connect with createClient and a redis:// URL:

const { createClient } = require('redis');

const client = createClient({
  url: `redis://:${process.env.REDIS_PASSWORD}@${process.env.REDIS_HOST}:${process.env.REDIS_PORT}`,
});
client.on('error', (err) => console.error('Redis error:', err));

async function start() {
  await client.connect();
  console.log('Connected to Redis');

  await client.set('greeting', 'hello');
  console.log(await client.get('greeting')); // "hello"
}

start();

💡 Tip: Mind the URL shape: redis://:PASSWORD@host:port. The username is empty, so the password comes straight after the colon.

The feature that makes Redis a cache is expiry. Pass { EX: seconds } to set and the key deletes itself when the time's up — no cleanup code. A command cooldown is three lines:

// true = allowed, false = still cooling down
async function checkCooldown(userId) {
  const key = `cooldown:${userId}`;
  if (await client.get(key)) return false;   // key still there → too soon
  await client.set(key, '1', { EX: 60 });    // gone automatically in 60s
  return true;
}

The same idea powers rate limits (count requests under a key with a short EX) and session tokens (store the session under a random key with an EX matching its lifetime).

What to cache — and what never to

Cache it — temporary or reproducible Never keep only in Redis
Cooldowns and rate limits Users
Session tokens and short-lived login state Orders
Hot data you can always recompute — a leaderboard, an expensive query's result, an API response you don't want to re-fetch Posts and bot configuration

What must not live only in Redis is the single copy of anything you can't afford to lose. It's a cache, not a safe: a reinstall or application switch wipes it outright, and although Redis snapshots to disk between saves, a crash can still drop everything written since the last one. Durable records belong in a managed database (connect it like this). Cache in front of that database; never replace it.

Using Python instead?

The redis-py package (redis on PyPI, installable from the Packages page) gives you the same set / get / expire API from Python — the pattern above translates directly.

Troubleshooting

  • Connection refused or timeouts — wrong host/port, or the Redis server is stopped. Use the Redis server's address and port from its Network page (or its internal address), and make sure it's running; on free, its timer may have expired.
  • NOAUTH / WRONGPASS — the password is missing or wrong in the URL. Copy the Redis Password variable exactly, and keep the leading colon: redis://:PASSWORD@host:port.
  • The cache came back empty — a reinstall or application switch wipes Redis's stored snapshot, and a hard crash can lose writes since the last save. Keep nothing in Redis you can't rebuild.
  • Everything broke at once — the Redis server went offline and every dependent app lost its cache. Keep Redis on an always-on server, or make your code cope when a get returns nothing.

Next steps

Was this guide helpful?