Cache Django with Redis

Django’s cache framework keeps computed views and values in a cache backend. On Sevalla, the backend is a Redis database that the application reaches over an internal connection, so every instance of the web process shares one cache. Django includes the Redis backend: it needs only the redis package.

At a glance

This guide adds to the application from Deploy a Django application:


Services	A Redis or Valkey database over an internal connection, next to the PostgreSQL database
Size	DB1 for the Redis database

Environment variables

Variable	Required	Available during	Secret	Value
`REDIS_URL`	Yes	Build and runtime	Yes	Added by the internal connection to `storefront-redis`: `redis://:<password>@<host>:<port>/0`

The internal connection also adds REDIS_HOST, REDIS_PORT and REDIS_PASSWORD, which the project doesn’t read. The deploy guide lists the other variables.

Before you begin

A Django project deployed on Sevalla, as in Deploy Django.

Create a Redis database

Create the database

In the sidebar, click Databases, then click Create database. Under Database, choose Redis, or Valkey: the code in this guide works with both. Enter storefront-redis as the Display name, choose the same Data center as the application and a Size, then click Create database.

Connect it to the application

In the sidebar, click Applications, then click the application. Click the Networking tab. Under Connected services, click Add internal connection. Choose storefront-redis as the Service, turn on Add environment variables to the application, and click Add internal connection. Sevalla adds REDIS_HOST, REDIS_PORT, REDIS_PASSWORD and REDIS_URL. See Connect an application.

The Add internal connection sheet with the Service field and the Add environment variables to the application switch

Configure the cache

Install redis-py and update requirements.txt:

pip install redis
pip freeze > requirements.txt

In storefront/settings.py, use Django’s Redis backend with the URL from the internal connection:

storefront/settings.py

# A Valkey URL added before Oct 30, 2026 starts with valkey://, which redis-py doesn't accept.
REDIS_URL = env("REDIS_URL", default="redis://localhost:6379/0").replace("valkey://", "redis://", 1)

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": REDIS_URL,
    }
}

The same setting serves cache_page, template fragment caching ({% cache %}) and the low-level API (django.core.cache.cache).

Cache a view

Cache a view’s response for 2 minutes with cache_page:

storefront/views.py

from django.http import HttpResponse
from django.utils import timezone
from django.views.decorators.cache import cache_page


@cache_page(60 * 2)
def cached(request):
    return HttpResponse(f"Generated at {timezone.now():%H:%M:%S}")

storefront/urls.py

from django.contrib import admin
from django.urls import path

from storefront.views import cached

urlpatterns = [
    path("admin/", admin.site.urls),
    path("cached/", cached),
]

Commit and push the changes, requirements.txt included: Ingot installs redis on the next build. If Auto-deploy is off, click Deploy now on the application’s Overview tab.

Verify

When the deployment’s status is Deployed, request the page twice, with your application’s domain:

curl https://storefront-x7k2m.sevalla.app/cached/
curl https://storefront-x7k2m.sevalla.app/cached/

Both responses show the same time, for example Generated at 16:08:48, and carry Cache-Control: max-age=120. After 2 minutes, the next request shows a new time. To see both in one run:

curl -s https://storefront-x7k2m.sevalla.app/cached/; echo
curl -s -D - -o /dev/null https://storefront-x7k2m.sevalla.app/cached/ | grep -i '^cache-control'
curl -s https://storefront-x7k2m.sevalla.app/cached/; echo

Generated at 16:08:48
cache-control: max-age=120
Generated at 16:08:48

To check the cache itself, run a command in the web process with Run a command in a process (execProcessCommandV3), with APP_ID and WEB_ID from Deploy with the API:

curl -s -X POST "$API/applications/$APP_ID/processes/$WEB_ID/exec" \
  -H "Authorization: Bearer $SEVALLA_API_KEY" -H "Content-Type: application/json" \
  -d '{"command": ["python", "manage.py", "shell", "-v", "0", "-c", "from django.core.cache import cache; cache.set(\"check\", \"ok\"); print(cache.get(\"check\"))"]}'

{"stdout":"ok\n","stderr":"","exit_code":0}

To look at the keys, open the database and click the Redis studio tab: cache_page stores keys whose names start with :1:views.decorators.cache.cache_page. See Database studio.

Control the CDN and edge cache

Sevalla can also cache responses at Cloudflare’s edge, in front of the application. Turn on the CDN and edge caching on the application’s Networking tab; see CDN and edge caching.

The CDN caches static files by file extension, such as .css, .js and images. WhiteNoise’s hashed file names make them safe to cache for a long time.
Edge caching caches pages and other responses too. It caches only GET requests, skips requests with an Authorization header, and doesn’t store responses that set a cookie, such as pages that start a session or set the CSRF cookie.
When a response has no Cache-Control header, Sevalla adds one. With edge caching on, a 200 response without its own header can stay cached for up to 30 days, unless a deployment or a purge clears the cache first. See Control caching from your application.

So with edge caching on, set Cache-Control on every view. never_cache keeps a page out of every cache, and cache_control sets how long it may be kept:

storefront/views.py

from django.views.decorators.cache import cache_control, never_cache


@never_cache
def account(request):
    ...


@cache_control(public=True, max_age=600)
def catalog(request):
    ...

Django’s admin views already use never_cache. To check what a page sends, run curl -sI https://storefront-x7k2m.sevalla.app/catalog/ and read the Cache-Control header.

Deploy with the API

This sequence adds the Redis database to the application from Deploy with the API and continues in its shell, with API, CLUSTER_ID, DB1_ID and APP_ID set. Push the code changes from Configure the cache and Cache a view first. Each step names the CLI command and the Sevalla MCP server tool that do the same.

Look up the Redis version

List database versions (listDatabaseVersionsV3) returns the versions the location offers, oldest first. Save the newest:

REDIS_VERSION=$(curl -s "$API/resources/database-versions?cluster_id=$CLUSTER_ID&type=redis" \
  -H "Authorization: Bearer $SEVALLA_API_KEY" | jq -r '.[0].versions[-1]')

CLI: sevalla resources db-versions --cluster "$CLUSTER_ID" --type redis. MCP: not needed, create_database takes the newest version by default.

Create the database

Create database (createDatabaseV3). You choose the password, and the API never returns it, so keep it for the connection URL:

REDIS_PASSWORD=$(openssl rand -hex 16)
REDIS_ID=$(curl -s -X POST "$API/databases" \
  -H "Authorization: Bearer $SEVALLA_API_KEY" -H "Content-Type: application/json" \
  -d "$(jq -n --arg cluster "$CLUSTER_ID" --arg size "$DB1_ID" --arg version "$REDIS_VERSION" --arg password "$REDIS_PASSWORD" \
    '{display_name: "storefront-redis", type: "redis", version: $version, cluster_id: $cluster,
      resource_type_id: $size, db_name: "storefront", db_password: $password}')" \
  | jq -r .id)

CLI:

sevalla databases create --name storefront-redis --type redis --db-version "$REDIS_VERSION" --cluster "$CLUSTER_ID" --resource-type "$DB1_ID" --db-name storefront --db-password "$REDIS_PASSWORD"

. MCP: create_database with type: "redis"; with connect_to_application_id and env_var_name: "REDIS_URL", it also does the internal connection and adds REDIS_URL.

Wait for the database

Get database (getDatabaseV3) shows status ready when the database is up, with its internal hostname and port:

for i in $(seq 1 60); do
  [ "$(curl -s "$API/databases/$REDIS_ID" -H "Authorization: Bearer $SEVALLA_API_KEY" | jq -r '.status // empty')" = ready ] && break
  sleep 10
done
REDIS=$(curl -s "$API/databases/$REDIS_ID" -H "Authorization: Bearer $SEVALLA_API_KEY")
REDIS_HOST=$(echo "$REDIS" | jq -r .internal_hostname)
REDIS_PORT=$(echo "$REDIS" | jq -r .internal_port)

CLI: sevalla databases get "$REDIS_ID". MCP: get_database.

Connect the database

Create internal connection (createApplicationInternalConnectionV3):

curl -s -X POST "$API/applications/$APP_ID/internal-connections" \
  -H "Authorization: Bearer $SEVALLA_API_KEY" -H "Content-Type: application/json" \
  -d "$(jq -n --arg db "$REDIS_ID" '{target_id: $db, target_type: "database"}')" | jq -r .id

The API adds no environment variables; the next step adds them. CLI: sevalla apps internal-connections create "$APP_ID" --target-id "$REDIS_ID" --target-type database. MCP: sevalla_api_create with createApplicationInternalConnectionV3 and the same body.

Add the environment variables

Create environment variable (createEnvironmentVariableV3), once per variable, with the names and format of the dashboard’s internal connection:

for pair in "REDIS_HOST=$REDIS_HOST" "REDIS_PORT=$REDIS_PORT" "REDIS_PASSWORD=$REDIS_PASSWORD" \
  "REDIS_URL=redis://:$REDIS_PASSWORD@$REDIS_HOST:$REDIS_PORT/0"; do
  curl -s -X POST "$API/applications/$APP_ID/env-vars" \
    -H "Authorization: Bearer $SEVALLA_API_KEY" -H "Content-Type: application/json" \
    -d "$(jq -n --arg key "${pair%%=*}" --arg value "${pair#*=}" '{key: $key, value: $value, is_runtime: true, is_buildtime: true}')" \
    | jq -r .key
done

CLI: sevalla apps env-vars create "$APP_ID" --key REDIS_URL --value "redis://:$REDIS_PASSWORD@$REDIS_HOST:$REDIS_PORT/0", once per variable. MCP: set_environment_variables.

Deploy

Trigger deployment (triggerDeploymentV3) deploys the latest commit with the Redis variables. With Auto-deploy on, the push already started a deployment, without them; this one queues behind it:

DEPLOYMENT_ID=$(curl -s -X POST "$API/applications/$APP_ID/deployments" \
  -H "Authorization: Bearer $SEVALLA_API_KEY" -H "Content-Type: application/json" -d '{}' | jq -r .id)

CLI: sevalla apps deployments trigger "$APP_ID". MCP: trigger_deployment.

Wait for the deployment

Get deployment (getDeploymentV3) reports the status, which ends as success, failed, cancelled or skipped. The loop keeps polling through a failed request, for up to 30 minutes:

for i in $(seq 1 120); do
  STATUS=$(curl -s "$API/applications/$APP_ID/deployments/$DEPLOYMENT_ID" \
    -H "Authorization: Bearer $SEVALLA_API_KEY" | jq -r '.status // empty')
  case $STATUS in success|failed|cancelled|skipped) break ;; esac
  sleep 15
done
echo "$STATUS"

CLI: sevalla apps deployments get "$DEPLOYMENT_ID" --app-id "$APP_ID". MCP: get_deployment.

Then run the checks in Verify, with your application’s domain.

Get started

Migrate

AI

JavaScript

Python

PHP

Ruby

Go

Rust

Java, Kotlin and Scala

.NET

Elixir

Gleam

Swift

Dart

Static site generators

Cache Django with Redis

At a glance

Environment variables

Before you begin

Create a Redis database

Configure the cache

Cache a view

Verify

Control the CDN and edge cache

Deploy with the API

​At a glance

​Environment variables

​Before you begin

​Create a Redis database

​Configure the cache

​Cache a view

​Verify

​Control the CDN and edge cache

​Deploy with the API

At a glance

Environment variables

Before you begin

Create a Redis database

Configure the cache

Cache a view

Verify

Control the CDN and edge cache

Deploy with the API