I have a Redis instance running on my server and it is only accessible locally. It is not exposed to the public internet and is used internally by my application services.
The challenge is that I still need a convenient way to inspect data, debug issues, and occasionally verify what is happening inside Redis without SSH-ing into the server every time.
For this, I use RedisInsight, which is a useful tool for inspecting keys, checking runtime state, and debugging Redis behavior. The issue is that RedisInsight does not have any built-in authentication or user management. Once exposed over HTTP, there is no native way to restrict access, so authentication has to be handled externally.
After looking around for a while, I ended up using oauth2-proxy in front of RedisInsight, with Nginx handling TLS termination and request routing. The setup is fairly straightforward, and this is how I wired it up.
RedisInsight container (local-only service)
The first step was to run RedisInsight as a local-only Docker service. It is bound to localhost so it cannot be accessed externally, and only processes running on the machine can reach it.
docker run -d \
--name redisinsight \
--restart unless-stopped \
-p 127.0.0.1:5540:5540 \
redis/redisinsight:latest
This ensures the service is not exposed to the internet and is only accessible locally. At this stage, RedisInsight is fully functional but not reachable from outside the server.
oauth2-proxy setup (authentication layer)
To add access control, I use oauth2-proxy as an authentication layer in front of RedisInsight. In this setup, it runs as a system service on the host machine and is managed via a configuration file. It could also be deployed as a container, but keeping it on the host keeps the setup simpler.
It listens locally on port 4180 and Nginx forwards authentication requests to it. It handles Google OAuth login and enforces an email allowlist before granting access.
oauth2-proxy \
--provider=google \
--email-domain="*" \
--authenticated-emails-file=/etc/oauth2-proxy/emails.txt \
--upstream=http://127.0.0.1:5540 \
--http-address=127.0.0.1:4180 \
--cookie-secure=true \
--cookie-secret="YOUR_RANDOM_SECRET" \
--client-id="YOUR_GOOGLE_CLIENT_ID" \
--client-secret="YOUR_GOOGLE_CLIENT_SECRET" \
--redirect-url="https://<your-domain>/oauth2/callback"
The allowlist is defined in a simple file:
user1@example.com
user2@example.com
Nginx configuration
Nginx acts as the public entry point and ensures all traffic is authenticated before reaching RedisInsight. It handles HTTPS termination, routes OAuth-related endpoints to oauth2-proxy, and protects the main UI using an authentication check.
server {
server_name <your-domain>;
location /oauth2/ {
proxy_pass http://127.0.0.1:4180;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Auth-Request-Redirect $request_uri;
}
location = /oauth2/auth {
proxy_pass http://127.0.0.1:4180;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Content-Length "";
proxy_pass_request_body off;
}
location / {
auth_request /oauth2/auth;
error_page 401 = /oauth2/sign_in;
proxy_pass http://127.0.0.1:5540;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 3600;
}
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/<cert>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<cert>/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}
Google OAuth configuration
In Google Cloud Console, the OAuth client is configured as a standard web application. This connects oauth2-proxy to Google’s identity system and enables login and session handling.
Setup steps:
- Go to Google Cloud Console → APIs & Services → Credentials
- Create Credentials → OAuth client ID
- Select Web application
- Give it a name (e.g. redisinsight-auth)
The redirect URI must match exactly:
https://<your-domain>/oauth2/callback
After creation, Google provides a Client ID and Client Secret, which are used in the oauth2-proxy configuration.
If the OAuth consent screen is in testing mode, test users must be explicitly added or login will fail even if the configuration is correct.
Once configured, oauth2-proxy handles the full flow: redirecting to Google login, validating identity, creating a session, and enforcing the allowlist before forwarding requests.
Security note
Redis can also be configured with a password (requirepass) for an additional layer of protection. Even though Redis is already not exposed externally in this setup, enabling authentication can still help reduce risk in case of misconfiguration or accidental exposure.
Request flow in practice
When accessing the RedisInsight UI, the request first hits Nginx, which triggers an authentication check through /oauth2/auth. If the user is not authenticated, they are redirected to Google login. Once authenticated, oauth2-proxy validates the email against the allowlist and forwards the request to RedisInsight.
From there, RedisInsight connects to Redis internally, which remains fully isolated from external access.