Want SyneHQ to query data that lives only inside your network or on your laptop? Local Connections let you create a secure tunnel so your database stays private and SyneHQ can still reach it—no firewall surgery, no public exposure.
What you’ll do (2 minutes)
- Create a tunnel in SyneHQ to get a secure
token
andport
- Point your database connection in SyneHQ to
localhost:<port>
- Start the Rabbit CLI to open the secure TCP tunnel
Open TCP Tunnel in SyneHQ
Create a tunnel to receive your token and port
Add a Connection
Use localhost and your tunnel port for the host/port
Step-by-step
) Create a tunnel in SyneHQ
) Create a tunnel in SyneHQ
- Go to the Tcp Tunnel page (sidebar) → Tunnels
- Click Create Tunnel to generate your token and port
- Copy both; you’ll need them for the CLI
These credentials only allow access through the secure tunnel—your database itself stays private.

) Add your database connection in SyneHQ
) Add your database connection in SyneHQ
- Navigate to Add Connection
- Set the host to
localhost
- Set the port to the value from your tunnel
- Enter DB credentials as usual

Using
localhost
makes your database appear local to SyneHQ—traffic still flows through the encrypted tunnel.) Install and run the Rabbit CLI
) Install and run the Rabbit CLI
- Install via curl
- Install via wget
Only run install scripts you trust. Review the script if your security policy requires it.
- Use your actual
YOUR_TOKEN
from step 1 - Set
--local-port
to your service’s real port (e.g., 5432 for Postgres)
That’s it—you can now query your private data from SyneHQ without exposing it to the internet.
What the tunnel does (plain English)
- Creates an encrypted TCP channel from your machine/network to SyneHQ
- Keeps your database private—no inbound rules or public endpoints required
- Automatically reconnects with exponential backoff if the network blips
- Works great for dev and production with health checks and graceful shutdown
Quick example: Local PostgreSQL
Best practices
Tip | Why it helps |
---|---|
Store tokens in env vars | Avoids accidental leakage in shell history and scripts |
Use limited retries in dev | Keeps logs clean; --max-retries 0 for dev is fine |
Run under a supervisor | Use Docker, systemd, or PM2 for HA and auto‑restart |
Restrict DB credentials | Least-privilege DB user reduces blast radius |
Troubleshooting
Tunnel connects, but DB won't
Tunnel connects, but DB won't
- Verify DB accepts connections from
localhost
- Check the port matches your service (e.g., 5432 for Postgres)
- Confirm DB user/password and database name
SSL or cert errors
SSL or cert errors
- Ensure your DB SSL mode matches your setup (disable in local dev if needed)
- Behind corporate proxies? Check proxy/SSL inspection rules
High latency or drops
High latency or drops
- Prefer wired over flaky Wi‑Fi for long‑running sessions
- Try a closer region or contact support for routing help
For advanced usage, configuration flags, and integration scenarios, see the full Rabbit Tunnel Client guide.
Tunnel Client Usage Guide
Explore advanced flags, service configs, and automation patterns