Back to Blog

28 Mar 2026

Setting Up Redis in Django

Learn how to set up Redis in your Django app the simple way. From installing on Ubuntu to caching, sessions, and even a touch of WebSockets - without the usual overcomplicated explanations.

Setting Up Redis in Django

Redis is one of those things that gets mentioned all the time when people talk about scaling Django apps, and just like a lot of topics in web development, it’s usually explained in a way that makes it sound far more complicated than it actually is.

In reality, it’s very straightforward to set up, and once you’ve got it running, it opens the door to things like caching, faster sessions, background tasks and even real-time features.

In this tutorial, I’ll walk you through getting Redis installed on Ubuntu, wiring it into Django, and briefly touching on how it fits into WebSockets later on.

Let’s get it installed first.

SSH into your server and run the following commands: 



# Update packages
sudo apt update

# Install Redis
sudo apt install redis-server

Now let’s start Redis and make sure it runs on boot: 



sudo systemctl start redis
sudo systemctl enable redis

Quick check to make sure it's working: 



redis-cli ping

You should see PONG. If you do, nice — Redis is up and running.

Before we hook it into Django, let’s quickly configure it properly.

Open the Redis config file: 



sudo nano /etc/redis/redis.conf

Make sure Redis is bound to localhost: 



bind 127.0.0.1 ::1

And if you want to be a bit safer, you can also set a password: 



requirepass yourstrongpassword

Save the file and restart Redis: 



sudo systemctl restart redis

Nice. That’s Redis configured.

Now let’s get it into Django.

Activate your virtual environment and install the required packages: 



pip install redis django-redis

Now head over to your settings.py and add the following: 



# ~/myproject/settings.py

CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/1",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
            "PASSWORD": "yourstrongpassword",
        }
    }
}

That’s all Django needs to start using Redis as a cache.

Let’s quickly test it. 



# python manage.py shell

from django.core.cache import cache

cache.set("test_key", "hello world", timeout=60)
print(cache.get("test_key"))

If you see hello world printed back — you’re good.

Cache sorted.

Now let’s actually use it for something useful.

A common use case is caching expensive queries: 



from django.core.cache import cache
from .models import Product

def get_products():
    products = cache.get("products")

    if not products:
        products = Product.objects.all()
        cache.set("products", products, timeout=60)

    return products

Now instead of hitting your database every time, Redis will serve it instantly.

Next up — sessions.

If you want Django sessions to run through Redis instead of your database, add this to your settings.py: 



SESSION_ENGINE = "django.contrib.sessions.backends.cache"
SESSION_CACHE_ALIAS = "default"

This means authentication, sessions and messages are all handled by Redis instead of writing to your database constantly.

If you want a safer approach with persistence, you can use: 



SESSION_ENGINE = "django.contrib.sessions.backends.cached_db"

That gives you the best of both worlds.

Now just briefly touching on something you might want later — WebSockets.

Redis is what Django Channels uses to communicate between connections, so if you ever want real-time features like chat or live updates, this is where it comes in.

Install the required packages: 



pip install channels channels-redis

Then add this to your settings.py: 



ASGI_APPLICATION = "myproject.asgi.application"

CHANNEL_LAYERS = {
    "default": {
        "BACKEND": "channels_redis.core.RedisChannelLayer",
        "CONFIG": {
            "hosts": [("127.0.0.1", 6379)],
        },
    },
}

That’s all you need for Redis to act as a message broker.

We won’t go deeper into Channels here, but now you know where Redis fits into that picture.

Taking it a step further (recommended for production)

If you're just experimenting or running everything locally, the setup above will work absolutely fine.

However, if you're planning to use Redis in a real project, it's worth taking a few extra minutes to secure it properly using an ACL (Access Control List).

This replaces the single-password approach with named users and gives you much more control over access.

Securing Redis properly with an ACL file

For simple local development, you will often see Redis set up with a single password using requirepass. That works, but a more flexible and recommended approach is to use an ACL file.

ACL stands for Access Control List. It lets you create named Redis users, assign passwords to them, and control exactly what they are allowed to do. This is cleaner, more secure, and much easier to manage if you ever want to separate app access from admin access.

For example, instead of giving every part of your stack the same full-access password, you could create:

  • one user for your Django app
  • one user for background workers
  • one admin user for manual maintenance

In many real deployments, this is a much better option than relying on a single shared password.

Step 1: Create an ACL file

Create a new ACL file somewhere only privileged users can edit. A common location is:

sudo nano /etc/redis/users.acl

Then add something like this:

user default off
user django_app on >REPLACE_WITH_A_STRONG_PASSWORD ~* +@all
user redis_admin on >REPLACE_WITH_ANOTHER_STRONG_PASSWORD ~* +@all

Here is what that means:

  • user default off disables the default Redis user, which is a good idea if you want to force named-user authentication.
  • user django_app on creates and enables a user called django_app.
  • >password sets that user's password.
  • ~* allows access to all keys.
  • +@all allows all command categories.

If you want to be stricter, you can reduce the allowed commands later, but for many app setups this is a practical starting point.

Step 2: Tell Redis to use the ACL file

Open your Redis configuration file:

sudo nano /etc/redis/redis.conf

Find or add this line:

aclfile /etc/redis/users.acl

If you were previously using requirepass, remove it or comment it out so you are not mixing approaches unnecessarily.

Step 3: Decide whether Redis should be local-only or remotely accessible

If Redis is only being used by Django on the same server, keep it local-only. That is the safest option.

In that case, make sure Redis is bound only to localhost:

bind 127.0.0.1 ::1
protected-mode yes

This means only services running on the same machine can connect.

If your Django app is running on a different server and needs to connect remotely, you will need to allow Redis to listen on a real network interface and carefully restrict access using your firewall.

Step 4: Example remote setup

Let us say:

  • your Redis server is 203.0.113.10
  • your Django app server is 198.51.100.25

On the Redis server, update your Redis config:

sudo nano /etc/redis/redis.conf

Change the bind line so Redis listens on the server's network interface as well:

bind 127.0.0.1 203.0.113.10
protected-mode yes
port 6379

You could also use 0.0.0.0, but that is usually broader than necessary. Binding specifically to the server's actual IP is better.

Now lock it down with your firewall so only your Django server can reach Redis.

With UFW, for example:

sudo ufw allow from 198.51.100.25 to any port 6379 proto tcp

That allows only your app server to connect to Redis on port 6379.

If you do this, do not also open port 6379 to the whole internet.

Step 5: Restart Redis

sudo systemctl restart redis-server
sudo systemctl status redis-server

If Redis fails to restart, check the logs:

sudo journalctl -u redis-server -n 50 --no-pager

Step 6: Test authentication

From the Redis server itself, you can test with:

redis-cli --user django_app --pass 'REPLACE_WITH_A_STRONG_PASSWORD' ping

If everything is working, Redis should reply with:

PONG

If you are testing from a remote machine:

redis-cli -h 203.0.113.10 -p 6379 --user django_app --pass 'REPLACE_WITH_A_STRONG_PASSWORD' ping

Using the ACL user in Django

If you are connecting from Django, your Redis URL will now include both the username and password:

redis://django_app:REPLACE_WITH_A_STRONG_PASSWORD@127.0.0.1:6379/1

Or, for a remote Redis server:

redis://django_app:REPLACE_WITH_A_STRONG_PASSWORD@203.0.113.10:6379/1

A simple Django cache configuration example would look like this:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": "redis://django_app:REPLACE_WITH_A_STRONG_PASSWORD@127.0.0.1:6379/1",
    }
}

If you are using Redis for sessions as well, you would point that package or session backend at the same authenticated Redis URL.

A note on safety

If Redis is on the same machine as your Django app, there is usually no need to expose it remotely at all. Keeping Redis bound to localhost is the simpler and safer option.

If you do need remote access, use all of the following together:

  • an ACL user with a strong password
  • a firewall rule restricted to the trusted app server IP only
  • Redis protected mode
  • no public open access to port 6379

That way, you are not just relying on a password alone.

And that’s pretty much it.

Redis is one of those things that seems like a “later problem”, but honestly it’s worth putting in early. It’ll make your app faster, reduce database load, and set you up nicely for scaling.

Give it a go, play around with caching different parts of your app, and you’ll quickly see where it shines.

Happy coding! 😁