Passwordless database access via Tailscale identity and Vault credentials
A proxy that authenticates clients using their existing Tailscale identity, eliminating shared database passwords while supporting PostgreSQL and ClickHouse in a single process.
- LinkLoot access
- Free
- Provider costs
- Unknown
What you get from it
What it does
tailscale-database-gateway is a proxy that lets users connect to databases without managing individual credentials. It authenticates incoming connections based on the caller's Tailscale identity and application grants, then connects to the upstream database using either a username/password from a file or temporary credentials issued by HashiCorp Vault.
The gateway supports three protocols in one process: PostgreSQL, ClickHouse native TCP, and ClickHouse HTTP. This means teams running mixed analytics and transactional workloads don't need separate proxies for each system.
Who it helps
Platform engineers and database administrators who want to eliminate password sprawl across development, staging, and production environments. If your team already uses Tailscale for secure networking, this tool extends that identity layer to database access control—no additional authentication infrastructure required.
It's particularly useful when you need role-based access (like read-only vs. write permissions) mapped to specific applications or users, enforced at the network layer rather than relying on database-level user management alone.
Getting started
Deploy the published container image (ghcr.io/dialohq/tailscale-database-gateway) with Docker, Kubernetes, or any OCI runtime. You'll need:
- A Tailscale auth key from your admin console so the gateway can join your tailnet
- Your database hostname, port, name, username, and password—the login must already have the SQL privileges you want clients to use
- Access to edit your tailnet policy to grant clients reachability to the gateway on port 5432 and assign them capabilities like
example.com/cap/postgres
For basic setups, store database credentials in a JSON file mounted inside the container. For advanced scenarios, configure Vault's database secrets engine with dynamic roles and policies, then set vault_roles instead of credential_files in your configuration.
Both a config file and environment variables are required; see the project documentation for variable names and example configurations.
Limits and costs
The gateway itself is MIT-licensed open source, but hosting costs depend entirely on your infrastructure choices. Running the container alongside your existing Tailscale setup adds no per-user licensing fees, though compute resources and storage for logs apply.
Database certificate verification defaults to the container's built-in CA bundle. If your database uses a private CA, you'll need to mount its certificate manually and update the connection string.
Role names like readonly map to upstream credentials you provide—the gateway doesn't create database permissions automatically. Ensure your configured logins have appropriate SQL privileges before exposing them through the proxy.
Source links
Discussion
Share practical experience, questions, or warnings with the community.
Sign in to join the discussion and vote on comments.
Sign in