Redis

Deploy fully managed Redis instances on Hostess for caching, session storage, task queues, and real-time features.

Overview

The redis service type provisions a fully managed Redis instance. Like PostgreSQL, Redis is a managed service — you do not need to provide a Dockerfile or build configuration. Hostess handles provisioning, configuration, and connection management for you.

hostess.yml

services:
  cache:
    type: redis

That is the simplest possible Redis service. Hostess provisions a Redis instance with medium resources (1 CPU, 1Gi memory) and makes it available to other services via magic variables.

Defaults

When you use type: redis, Hostess applies the following defaults:

Setting	Default Value
Port	`6379`
Health check	Built-in Redis ping
Resources	`medium` (1 CPU, 1Gi memory)
Retention	`ephemeral`
Backups	Not configured (must be explicitly enabled)

Resource Presets and Storage

Redis instances need CPU and memory for runtime. Since Redis holds data in memory, the memory allocation is particularly important — it directly determines how much data your Redis instance can store. Storage applies when you set retention: permanent.

hostess.yml

services:
  cache:
    type: redis
    resources: medium

Preset	CPU	Memory	Persistent Storage
`small`	0.5 cores	512Mi	10Gi
`medium`	1.0 cores	1Gi	20Gi
`large`	2.0 cores	2Gi	50Gi
`xlarge`	4.0 cores	4Gi	100Gi

hostess.yml

services:
  cache:
    type: redis
    resources:
      preset: large
      storage: 100Gi

hostess.yml

services:
  cache:
    type: redis
    resources:
      cpu: 1.0
      memory: 2Gi
      storage: 20Gi

Choosing the Right Resources

Use Case	Recommended Preset	Notes
Development and testing	`small`	512Mi is enough for light caching
Session storage	`small` or `medium`	Sessions are typically small; scale by user count
Application caching	`medium`	1Gi covers most cache workloads
Task queue (Celery)	`medium`	Queue messages are small; throughput matters more than memory
Real-time features	`large`	Pub/Sub and Streams benefit from more CPU and memory
Large dataset	`xlarge`	When you need to store significant amounts of data in-memory

Retention Policy

Redis data is temporary by default. Set retention: permanent when Redis should keep data across deploys and redeploys:

hostess.yml

services:
  cache:
    type: redis
    retention: permanent

Value	Description
`permanent`	Data persists across deployments and redeploys. Redis data is preserved.
`ephemeral`	Data is deleted when the deployment is destroyed.

For Redis used as a cache, ephemeral may be acceptable even in production since the data can be regenerated. However, if Redis is used for session storage, task queues, or as a primary data store, use permanent.

Connecting from Other Services

Other services connect to your Redis instance using magic variables. Hostess automatically constructs connection URLs for you.

Magic Variables

When you define a type: redis service, the following magic variables become available to any service that references it:

Variable	Description
`${cache.url}`	Redis connection URL with password and database number
`${cache.host}`	Redis hostname
`${cache.port}`	Redis port number
`${cache.password}`	Redis password

Replace cache with your actual service name. If your service is called redis, use ${redis.url}. If it is called queue, use ${queue.url}.

Basic Connection Example

hostess.yml

services:
  api:
    type: fastapi
    build:
      source: ./backend
    env:
      REDIS_URL: ${cache.url}
    depends_on:
      - cache

  cache:
    type: redis
    resources: small

The ${cache.url} magic variable resolves to a password-protected Redis connection string. Use split variables when a framework expects host, port, and password separately:

hostess.yml

env:
  REDIS_HOST: ${cache.host}
  REDIS_PORT: ${cache.port}
  REDIS_PASSWORD: ${cache.password}

Local Access

To connect to your Redis instance from your local machine, use the hostess connect command:

Terminal

hostess connect cache

This establishes a secure tunnel to your Redis instance and prints redis-cli commands you can run in another terminal. You can also choose the local port for use with GUI tools like RedisInsight:

Terminal

hostess connect cache --local-port 6379

Then connect your Redis client to localhost:6379.

See the CLI connect reference for all available options.

Common Patterns

Caching

The most common use case for Redis — cache frequently accessed data to reduce database load and improve response times:

hostess.yml

services:
  api:
    type: fastapi
    build:
      source: ./backend
    env:
      DATABASE_URL: ${database.url}
      REDIS_URL: ${cache.url}
    depends_on:
      - database
      - cache

  database:
    type: postgres
    resources: medium

  cache:
    type: redis
    resources: small

In your application:

app/cache.py

import redis.asyncio as redis
from app.config import settings

cache = redis.from_url(settings.redis_url)

async def get_user(user_id: str):
    # Check cache first
    cached = await cache.get(f"user:{user_id}")
    if cached:
        return json.loads(cached)

    # Fetch from database, cache the result
    user = await db.get_user(user_id)
    await cache.set(f"user:{user_id}", json.dumps(user), ex=3600)  # 1 hour TTL
    return user

Session Storage

Store user sessions in Redis for fast access and automatic expiration:

hostess.yml

services:
  api:
    type: fastapi
    build:
      source: ./backend
    env:
      DATABASE_URL: ${database.url}
      SESSION_STORE_URL: ${sessions.url}
    depends_on:
      - database
      - sessions

  database:
    type: postgres

  sessions:
    type: redis
    resources: small
    retention: permanent

Task Queue with Celery

Use Redis as a message broker for Celery task queues:

hostess.yml

services:
  api:
    type: fastapi
    build:
      source: ./backend
    env:
      DATABASE_URL: ${database.url}
      CELERY_BROKER_URL: ${queue.url}
      CELERY_RESULT_BACKEND: ${queue.url}
    depends_on:
      - database
      - queue

  worker:
    type: custom
    build:
      source: ./backend
    command: ["celery", "-A", "app.celery", "worker", "--loglevel=info"]
    env:
      DATABASE_URL: ${database.url}
      CELERY_BROKER_URL: ${queue.url}
      CELERY_RESULT_BACKEND: ${queue.url}
    depends_on:
      - database
      - queue
    replicas: 3

  database:
    type: postgres
    resources: medium

  queue:
    type: redis
    resources: medium

Separate Cache and Queue

For applications that use Redis for both caching and task queues, consider using separate Redis instances to isolate concerns:

hostess.yml

services:
  api:
    type: fastapi
    build:
      source: ./backend
    env:
      DATABASE_URL: ${database.url}
      CACHE_URL: ${cache.url}
      CELERY_BROKER_URL: ${queue.url}
    depends_on:
      - database
      - cache
      - queue

  cache:
    type: redis
    resources: small

  queue:
    type: redis
    resources: medium

Alternatively, use scoped databases (see below) to isolate workloads within a single Redis instance.

Scoped Databases

By default, all services that reference a Redis instance share the same keyspace (Redis database 0). If you need isolation between services or workloads, use scoped databases.

Redis scoped databases map to Redis numbered databases (0 through 15). Each group gets its own numbered database, so keys in one group do not collide with keys in another.

Explicit Group Map

hostess.yml

services:
  api:
    type: fastapi
    env:
      REDIS_URL: ${redis.url}
    depends_on:
      - redis

  worker:
    type: custom
    build:
      source: ./backend
    command: ["celery", "-A", "app.celery", "worker"]
    env:
      CELERY_BROKER_URL: ${redis.url}
    depends_on:
      - redis

  auth-service:
    type: fastapi
    build:
      source: ./services/auth
    env:
      SESSION_URL: ${redis.url}
    depends_on:
      - redis

  redis:
    type: redis
    databases:
      cache: [api]             # Redis database 0
      queue: [worker]          # Redis database 1
      sessions: [auth-service] # Redis database 2

In this setup, each group gets a different Redis database number in its connection URL. The api service uses database 0, the worker service uses database 1, and auth-service uses database 2.

Per-Service Sugar

If every consuming service should get its own isolated Redis database:

hostess.yml

services:
  redis:
    type: redis
    databases: per_service

Scoped Database Rules

A service that references ${<redis>.url} must belong to exactly one group
A service cannot appear in multiple groups for the same Redis instance
Group names must be DNS-safe

Redis supports a maximum of 16 database groups (numbered 0 through 15). If you define more than 16 groups, validation will fail.

Backups

Redis supports automatic scheduled backups:

hostess.yml

services:
  cache:
    type: redis
    backups: daily

For more control:

hostess.yml

services:
  cache:
    type: redis
    backups:
      schedule: daily
      retention: 14

See the PostgreSQL backups section for details on schedule presets and cron expressions — the configuration is identical.

Complete Examples

Simple Cache

hostess.yml

version: "1.0"

services:
  api:
    type: fastapi
    build:
      source: .
    env:
      REDIS_URL: ${cache.url}
    depends_on:
      - cache

  cache:
    type: redis

Production Redis with Backups

hostess.yml

version: "1.0"
name: my-app

services:
  api:
    type: fastapi
    build:
      source: ./backend
    env:
      DATABASE_URL: ${database.url}
      REDIS_URL: ${cache.url}
    depends_on:
      - database
      - cache

  database:
    type: postgres
    resources: large
    backups: daily

  cache:
    type: redis
    resources: medium
    retention: permanent
    backups:
      schedule: daily
      retention: 7

Scoped Redis for Multi-Workload

hostess.yml

version: "1.0"
name: multi-workload

services:
  api:
    type: fastapi
    build:
      source: ./backend
    env:
      DATABASE_URL: ${database.url}
      CACHE_URL: ${redis.url}
    depends_on:
      - database
      - redis

  worker:
    type: custom
    build:
      source: ./backend
    command: ["celery", "-A", "app.celery", "worker"]
    env:
      DATABASE_URL: ${database.url}
      CELERY_BROKER_URL: ${redis.url}
    depends_on:
      - database
      - redis
    replicas: 3

  auth-service:
    type: fastapi
    build:
      source: ./services/auth
    env:
      DATABASE_URL: ${database.url}
      SESSION_URL: ${redis.url}
    depends_on:
      - database
      - redis

  database:
    type: postgres
    resources: large

  redis:
    type: redis
    resources: medium
    databases:
      cache: [api]
      queue: [worker]
      sessions: [auth-service]

On this page