One Redis Instance for Multiple Websites: Safe Setup

This guide shows you how to run a single Redis server to serve multiple websites or applications without them interfering with each other. You’ll learn to isolate data by database number, use proper key prefixes, and set up authentication and access control. By the end, you’ll have a secure, multi-tenant Redis setup that prevents accidental data leaks and key collisions.

What You’ll Need

• A Linux server (or local machine) with Redis installed (version 6 or later recommended for ACLs).
• Root or sudo access to edit Redis configuration files.
• Basic familiarity with the command line and your application’s Redis client configuration.

Step-by-Step

1. Plan your database numbering. Redis has 16 logical databases by default (0–15). Assign each website a dedicated database number. For example, site A uses db 0, site B uses db 1, site C uses db 2. Document this mapping clearly.
2. Edit the Redis configuration file. Open /etc/redis/redis.conf (or your platform’s config path). Ensure databases 16 is set (or increase if you need more). If you want to prevent cross-database access via commands like MOVE, you can disable it by setting rename-command MOVE "" — but be careful, as this may break some clients.
3. Enable authentication with a strong password. Set requirepass YourStrongPassword in the config. This forces all clients to authenticate with AUTH before any command. Use a long random string, not a dictionary word.
4. Create separate Redis users with ACLs (Redis 6+). Instead of sharing the default user, define per-site users in the config or via ACL SETUSER. For example:

   user siteA on >SiteAPassword ~siteA:* +@all
   user siteB on >SiteBPassword ~siteB:* +@all

   This gives each site its own password and restricts key access to a prefix pattern. The ~siteA:* pattern means the user can only access keys starting with siteA:.

5. Use key prefixes consistently. Even with separate databases, always prefix keys with the site identifier, e.g., siteA:user:123. This provides a second layer of isolation and makes debugging easier. Update your application code to include the prefix in every key.
6. Configure your applications to use the correct database and credentials. In each site’s Redis client settings, specify the database number (e.g., db=0 for site A) and the appropriate password or username/password pair. For example, in a Python Redis client:

   redis.Redis(host='localhost', port=6379, db=0, username='siteA', password='SiteAPassword')

   Ensure the client does not fall back to the default database.

7. Test isolation. From the command line, connect as site A and try to read a key from site B’s database. Use redis-cli -a SiteAPassword -n 0 and attempt GET siteB:test. It should return an error (if ACLs are enforced) or an empty result (if only database separation). Verify that you cannot access keys outside your prefix.
8. Monitor and log. Enable Redis’s built-in slow log and monitor commands to detect unusual access patterns. Set slowlog-log-slower-than 10000 and slowlog-max-len 128 in the config. Review logs regularly.
9. Back up regularly. Use BGSAVE or set up a cron job to run redis-cli BGSAVE to create RDB snapshots. For more durable backups, use AOF persistence. Store backups in a secure location separate from the server.
10. Document the setup. Write down the database assignments, user credentials, and key prefix conventions. Share this with your team to prevent future misconfiguration.

Common Mistakes

• Using the same database for multiple sites without prefixes — this leads to key collisions and data leaks.
• Forgetting to set a password, leaving Redis exposed to the internet. Always bind to localhost or a private interface.
• Using the default user for all sites, which bypasses ACL restrictions.
• Not enabling ACLs because the Redis version is older — upgrade to 6+ for proper per-user permissions.
• Hardcoding credentials in code repositories. Use environment variables or a secrets manager.
• Assuming that separate databases are completely isolated — commands like FLUSHALL affect all databases, so be careful with admin commands.

Tips

• Use a naming convention like siteName:entity:id for keys. This makes it easy to filter and delete by prefix.
• For high-traffic sites, consider using separate Redis instances on different ports or even separate servers, but that’s outside the scope of this guide.
• Enable TLS for Redis connections if your data is sensitive. Configure tls-port and provide certificates.
• Set maxmemory and a maxmemory-policy to prevent one site from exhausting memory. For example, maxmemory 2gb and maxmemory-policy allkeys-lru.
• Use RENAME to disable dangerous commands like FLUSHALL or CONFIG for non-admin users.
• Regularly audit your ACLs and database usage with ACL LIST and INFO keyspace.

Troubleshooting

• Connection refused: Check that Redis is running (systemctl status redis) and that it’s listening on the expected interface. If it’s bound to 127.0.0.1, remote connections will fail — that’s actually good for security.
• Authentication errors: Ensure the password is correct and that the user has the right permissions. If using ACLs, verify the username and that the key pattern matches.
• Keys not visible: If you’re sure you set a key but can’t see it, you might be connected to a different database number. Check with SELECT and DBSIZE.
• Slow performance: Check SLOWLOG GET to see if any site is running expensive commands like KEYS *. Replace with SCAN.
• Memory issues: Use INFO memory to see usage. If one site is hogging memory, set per-database limits using maxmemory and maxmemory-policy — but note that Redis doesn’t support per-database limits natively, so you may need to monitor and enforce manually.
• ACL not working: After editing the config, restart Redis (sudo systemctl restart redis). If you used ACL SETUSER at runtime, make sure to save with ACL SAVE.

Frequently Asked Questions

1. Is it safe to share one Redis instance among multiple websites? Yes, if you use separate databases, strong authentication, and ideally ACLs with key prefixes. The main risk is human error, so documentation and testing are essential.
2. What is the maximum number of databases in Redis? The default is 16, but you can increase it by setting databases in the config. The practical limit is limited by memory and file descriptors, but 16 is usually enough for a handful of sites.
3. Can I use the same key name in different databases without conflict? Yes, each database is independent, so user:1 in db 0 and db 1 are different keys. However, using prefixes is still recommended for clarity.
4. What is the difference between using databases and using key prefixes? Databases provide logical separation, but commands like FLUSHALL affect all. Prefixes allow you to filter and manage keys more easily, and with ACLs you can enforce prefix-based access. Combining both is best.
5. How do I migrate an existing site to a new database number? You can use the MOVE command to move keys from one database to another, but it’s safer to write a script that reads from the old db and writes to the new one. Also update your application configuration.
6. Do I need to restart Redis after changing ACLs? If you use ACL SETUSER at runtime, changes take effect immediately. If you edit the config file, you need to restart or use ACL LOAD.

Related

• ERR_CERT_COMMON_NAME_INVALID: Fix It
• Skip MDM Lock? What It Is & How It Works
• UK University Research Centre vs Indian University Department