TempsTemps
On this page
  1. Creating a Redis Instance
  2. Manage from the CLI
  3. Connecting to Redis
  4. Common Use Cases
  5. Backups & Durability
  6. Monitoring
  7. Resource Limits
  8. Security
  9. Deleting the Service
  10. Pricing & Ownership

Managed Redis

A managed, high-performance Redis instance for caching, sessions, and pub/sub. Redis is one of the managed database services Temps runs as a container on your own infrastructure.

Provision and manage Redis three ways: the dashboard, the @temps-sdk/cli command-line tool (Manage from the CLI), or the REST API. If you use an AI coding agent (Claude Code, Cursor, Windsurf), install the temps-cli skill and just describe what you want.

Creating a Redis Instance

Via Dashboard:

  1. Navigate to Services → Create Service.
  2. Select Redis.
  3. Choose the image:
    • Redis 8 (Managed + WAL-G) — the recommended default (gotempsh/redis-walg:8-bookworm). This image pushes RDB snapshots to S3.
    • Custom image — bring your own (e.g. redis:7.2-alpine). Custom images support local snapshots only.
  4. Click Create Service.

On creation Temps auto-assigns a host port starting from 6379, creates a dedicated Docker volume at /data, and generates a password (minimum 8 characters) that protects the instance via requirepass.

Manage from the CLI

Provision and manage Redis from the terminal with the @temps-sdk/cli tool — the same flow worked end-to-end for PostgreSQL.

Create

# Log in once (stores credentials in ~/.temps)
bunx @temps-sdk/cli login

# Create the service. Set parameters with repeatable -s key=value flags;
# if a required one is missing the CLI fails fast and names it, so you
# can add it and re-run.
bunx @temps-sdk/cli services create -t redis -n my-cache -y

Inspect, link & manage

# List services and grab the numeric ID
bunx @temps-sdk/cli services list

# Full details, including the connection string
bunx @temps-sdk/cli services show --id 10

# Link to a project so REDIS_URL (and friends) are injected on deploy
bunx @temps-sdk/cli services link --id 10 --project-id 5
bunx @temps-sdk/cli services env --id 10 --project-id 5     # see injected vars
bunx @temps-sdk/cli services unlink --id 10 --project-id 5

# Lifecycle
bunx @temps-sdk/cli services stop --id 10
bunx @temps-sdk/cli services start --id 10
bunx @temps-sdk/cli services upgrade --id 10 -v redis:7.2-alpine
bunx @temps-sdk/cli services remove --id 10 -f             # destroys data

Prefer natural language? With the temps-cli skill installed, ask your AI agent to "create a Redis cache and link it to my project" and it runs these commands for you. The same services create -t <type> flow covers every managed database — see Managed PostgreSQL for the fully worked, parameter-by-parameter example.

Connecting to Redis

Node.js with ioredis

import Redis from 'ioredis';

// REDIS_URL is injected automatically when the service is linked
const redis = new Redis(process.env.REDIS_URL);

await redis.set('session:123', JSON.stringify(sessionData), 'EX', 3600);
const data = await redis.get('session:123');

Python with redis-py

import os
import redis

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

r.setex('session:123', 3600, json.dumps(session_data))
data = r.get('session:123')

Connection string format: redis://<password>@<host>:6379

When linked to a project, connection details are injected as REDIS_URL, REDIS_HOST, REDIS_PORT, REDIS_PASSWORD, and REDIS_DATABASE (the per-project logical database number). Connections happen over the Temps internal network — the port is not exposed publicly.

Common Use Cases

  • Name
    Session Storage
    Description

    Store user sessions with automatic expiration:

    await redis.set(`session:${userId}`, sessionData, 'EX', 86400); // 24 hours
  • Name
    Rate Limiting
    Description

    Implement rate limiting with Redis counters:

    const count = await redis.incr(`rate:${ipAddress}`);
if (count === 1) await redis.expire(`rate:${ipAddress}`, 60); // 60 seconds
if (count > 100) throw new Error('Rate limit exceeded');
  • Name
    Caching
    Description

    Cache expensive queries or API responses:

    const cached = await redis.get(`cache:${key}`);
if (cached) return JSON.parse(cached);

const data = await fetchExpensiveData();
await redis.set(`cache:${key}`, JSON.stringify(data), 'EX', 300); // 5 minutes
  • Name
    Pub/Sub
    Description

    Real-time messaging between services:

    await redis.publish('notifications', JSON.stringify(message));

redis.subscribe('notifications', (message) => {
  console.log('Received:', JSON.parse(message));
});

Backups & Durability

By default Redis keeps data in memory. The managed gotempsh/redis-walg image adds WAL-G, which pushes RDB snapshots to your configured S3 destination on a schedule you set (each schedule has its own retention window in days); custom images keep local snapshots only. Restore is snapshot-based (latest) — there is no point-in-time recovery.

Restore via the Temps CLI

temps services restore capabilities
temps services restore list-backups
temps services restore start

For workloads that absolutely cannot tolerate data loss, use PostgreSQL (which supports PITR) instead.

Monitoring

View live metrics and health in the dashboard's Services section — CPU & memory usage, connection count, disk usage, and uptime. Service-level monitoring is not yet exposed through the CLI.

Resource Limits

You can cap how much memory, swap, and CPU the service's container is allowed to use, and inspect what it's actually consuming. A service with no limits set runs unconstrained (the default). The same controls apply to every managed service type — PostgreSQL (standalone and cluster), MongoDB, Redis, RustFS, and S3.

The service detail page shows a Resources card that polls runtime status every 30 seconds and live usage every 5 seconds, plus an Edit limits dialog.

Editing limits

Open Services → select the service → Resources card → Edit limits. The dialog has independent Memory and CPU toggles:

FieldMeaningEmpty / off
MemoryHard memory cap, in MiBUnlimited
SwapExtra swap above the memory cap, in MiBNo extra swap
CPUCPU cap, in coresUnlimited

The Swap input means swap in addition to the memory limit — Memory = 512 and Swap = 256 lets the container use 512 MiB of RAM plus 256 MiB of swap. Internally Temps submits memory + swap to Docker. When a memory cap is set and the working set exceeds it, the kernel OOM killer terminates the container — that kill never reaches the app's own logs, so the oom_killed flag on the runtime endpoint is often the only signal.

Endpoints

All served under the /api prefix:

GET   /api/external-services/{id}/runtime
GET   /api/external-services/{id}/stats
PATCH /api/external-services/{id}/resources
  • GET …/runtime (ExternalServicesRead) — a per-container docker inspect snapshot: status, restart_count (a steady climb signals a crash loop), oom_killed, last exit_code, image, and the limits actually applied (so you can detect drift between configured and live caps).
  • GET …/stats (ExternalServicesRead) — a one-shot CPU/memory usage sample per container, cheap enough to poll every 5–10s. memory_percent is measured against the memory limit when one is set, or against host RAM otherwise.
  • PATCH …/resources (ExternalServicesWrite) — persists the caps to the service's encrypted config and live-applies them via Docker's update API (no restart needed). A request where every field is null removes all limits.

Security

  • Name
    Network Isolation
    Description
    • Reachable only from containers on the same Temps internal network — the port is never exposed to the public internet
    • Apps connect using the container name as the host, over private networking
    • Credentials are auto-generated at creation; you never have to choose a password
  • Name
    Credential Handling
    Description
    • Temps injects credentials as environment variables when the service is linked — never hard-code them
    • Credentials are stored encrypted at rest (see Encryption below)
    • Rotate them from Services → select service → Rotate Credentials; linked projects update automatically

Encryption

Credentials (passwords, access keys) are encrypted with AES-256-GCM before being written to the Temps database. The key lives at ~/.temps/encryption_key — protect this file and back it up separately from the database.

Database contents are not encrypted at the application layer by default. For encryption at rest, enable it at the infrastructure level — encrypted volumes or LUKS on bare metal; Temps does not manage disk encryption. In transit, traffic stays on the internal Docker network and is never exposed to the public internet.

Deleting the Service

Deleting the service permanently destroys all data and backups associated with it. This cannot be undone.

  1. Download a backup — Services → select the service → Backups → download the latest.
  2. Unlink all projects so no running app still holds a reference to the credentials.
  3. Delete the service from its settings page and confirm.

Pricing & Ownership

Because the service runs on your own infrastructure, there are no per-GB charges, connection caps, or metered bandwidth fees. A recommended starting allocation:

TierMemory
Small256 MB
Medium1 GB
Large4 GB+

Redis is built in — Vercel bills Vercel KV separately, Netlify is external-only, and Railway includes it. Your data never leaves your server; Temps (the company) has no access to it. See Data Ownership & Privacy for the full policy, including GDPR.

Was this page helpful?