Redis Access with Twingate
Securely connect to Redis Enterprise Cloud or self-hosted Redis using Twingate
Redis Access with Twingate
Redis is a high-performance, in-memory datastore used for caching, session storage, message queues, and more. Redis can run as a fully managed Redis Enterprise Cloud service or self-hosted on VMs or containers. Best practice is to keep Redis off the public internet and restrict inbound access to trusted networks only.
Twingate routes Redis traffic through secure Connectors, letting you enforce IP address or private endpoint restrictions without exposing your database publicly.
- Redis Enterprise Cloud: Securing Databases
- Redis Enterprise Cloud: Securing Subscriptions
- Self-hosted Redis: Securing Databases
Prerequisites
- Remote Network & Connector – Create a Remote Network in Twingate and deploy one or more Connectors:
- For self-hosted Redis, place Connectors inside the same VPC or LAN as the server and use their private IP addresses in firewall rules.
- For Redis Enterprise Cloud, capture each Connector’s public IP address to add to its allow list.
- Redis deployment – Either a Redis Enterprise Cloud instance or a self-hosted Redis server.
Tip: Use PrivateLink for Private Connectivity
If you are deploying in AWS, Azure, or GCP, Redis Enterprise Cloud supports PrivateLink (AWS/Azure) and Private Service Connect (GCP) for fully private connections.
With these features enabled:
- Your Connector connects to a private endpoint inside your VPC/VNet.
- All traffic stays on the cloud provider’s internal network fabric, bypassing the public internet entirely.
- No need to allowlist Connector public IP addresses in Redis Cloud security settings — access is automatically restricted to your private network.
See Redis documentation on Private Endpoints for provider-specific setup steps.
Redis Enterprise Cloud: Securing Databases
By default, Redis Enterprise Cloud databases use public endpoints. Paid plans support a CIDR allow list to restrict inbound access.
Step 1 – Create a Twingate Resource
- In the Twingate Admin Console, create a Resource for your Redis Cloud database host (e.g.
redis-12345.c15.us-east-1-4.ec2.redns.redis-cloud.com). - Set Port to the value shown in the Redis Cloud console (e.g.
12345based on the Public endpoint). - Record the public IP address(es) of your Connector(s).
Step 2 – Configure the CIDR allow list in Redis Cloud
- Log in to the Redis Cloud console.
- Open your database and navigate to Security → CIDR allow list.
- Enable the allow list and add each Connector’s public IP address in CIDR notation (e.g.
1.2.3.4/32). - Save changes — only these IP addresses will be able to connect.
Step 3 – Connect to Redis
With Twingate running:
redis-cli -h redis-12345.c15.us-east-1-4.ec2.redns.redis-cloud.com -p 12345 -a <password>Replace host, port, and password with values from your Redis Cloud instance.
Redis Enterprise Cloud: Securing Subscriptions
The Redis Enterprise Cloud admin console (app.redislabs.com or cloud.redis.io) lets you manage databases, billing, and user accounts. By default, it’s accessible from any IP address. Redis Cloud does not have a native IP allow list for access to the admin console, so you can gate access using Twingate and SSO. This section covers locking down Subscriptions and databases associated (and bring-your-own-cloud).
Tip: Combine with SSO for Identity-based Control
If your organization uses SSO (Okta, Azure AD, Google Workspace, etc.), you can also gate app.redislabs.com behind
SaaS App Gating for an extra layer of identity-based access control.
Step 1 – Create a Twingate Resource for the Admin Console
-
In the Twingate Admin Console, create a Resource for:
app.redislabs.com (previous domain) -or- cloud.redis.io (new domain)Port:
443(HTTPS) -
Use the same Remote Network that contains your database-access Connectors.
-
Record the public IP address(es) of those Connectors (Admin Console → Remote Network → Connectors → Public IP).
Step 2 – Restrict Access to Trusted IP Addresses
- Grant access to the
app.redislabs.comorcloud.redis.ioResource only to users/groups who need it. - Require users to be connected to Twingate to access the Subscription.
Step 3 – Verify Access via Twingate
- Run the Twingate Client and connect.
- Visit https://app.redislabs.com or https://cloud.redis.io.
- The subscription and databases should only load when traffic originates from an authorized Connector IP address.
Self-hosted Redis: Securing Databases
For Redis instances you manage:
-
Create a Twingate Resource targeting the server’s IP address or hostname and Redis port (default
6379). -
Restrict inbound traffic to the Connector’s private IP addresses via firewall rules or security groups. Only use public IP addresses if the Connector must reach the server over the internet.
-
(Optional) Harden Redis:
- In
redis.conf, setprotected-mode yes. - Use
bindto limit listening interfaces to those reachable via Twingate. - Require a strong password with
requirepass.
- In
-
Connect with
redis-clior your application via Twingate.
Troubleshooting Database Connections
If you’re having trouble connecting to your database via Twingate, check the following common issues:
-
Access denied: Verify Connector IP addresses are in the Redis Cloud CIDR allow list or firewall rules.
-
Authentication error: Check credentials and confirm
requirepassis configured properly. -
Port mismatch: Confirm the port in your Twingate Resource matches the Redis instance.
-
Slow Connections: Check the health of your Connectors and make sure there are no firewall rules blocking access to the database and timeouts are not in play.
-
Timeouts: Verify your Connectors are online, reachable, and properly configured.
-
Twingate Recent Activity: In the Admin Console, open Recent Activity for the Resource to see what’s happening:
-
DNS Failed: The Client sent traffic to the Connector, but the Connector couldn’t resolve the hostname. Ensure the DNS hosted zone is tied to the VPC, the DNS server is defined as a Twingate Resource (if self-hosting), or there’s a valid route from the Connector to the DNS server.
-
Connection Failed: The Client captured the traffic, sent it to the Connector, and the Connector tried but couldn’t reach the destination. Check that a route exists between the Connector and database, IP allow lists are correct, and firewall/security group rules allow the port on both ends.
-
No Activity: The Client didn’t send traffic to the Connector. Make sure the Client is running, you have access to the Resource, and no other VPN is hijacking the connection.
-
For more troubleshooting tips, refer to the Twingate Troubleshooting Guide.
Related Resources
Last updated 15 days ago