Database Access
The Database Access Gateway lets your team reach internal databases
over the mesh without exposing the database to the network and without
sharing the database host's location. An admin registers a database as a
resource and writes access rules that say who may reach it; a member then
opens a short-lived, audited connection from their own machine with the
meshr CLI and points any database client at localhost.
This is the Zero-Trust way to grant database access: nothing is reachable by default, every grant is explicit and time-boxed, and every connection is recorded — who connected, to which database, for how long, and how many bytes moved.
Why use it
- No exposed databases. The database keeps listening only on its host's own loopback interface. The gateway brokers connections through the mesh — there is no public port and no inbound firewall hole.
- Credential pass-through. Meshr never sees, stores, or asks for your database password. The database's own wire protocol and your client's credentials ride end-to-end through the brokered tunnel untouched.
- Time-boxed connections. Each access rule sets a maximum session duration; the gateway closes connections when the window ends.
- Connection-level audit. Every brokered session is logged for review in the dashboard.
How it works
┌──────────────┐ meshr db connect ┌───────────────┐ loopback ┌──────────┐
│ Your machine │ ───────────────────────► │ Meshr gateway │ ─────────────► │ Database │
│ psql / mysql │ 127.0.0.1:PORT │ (mesh-routed, │ 127.0.0.1 │ on host │
│ │ ◄─────────────────────── │ audited) │ ◄───────────── │ device │
└──────────────┘ raw DB protocol └───────────────┘ └──────────┘
- An admin registers a database (host device + engine + port) and grants access with access rules.
- A member runs
meshr db connect <name>, which opens a local listener on127.0.0.1. - The member points their database client at that local address. Bytes are brokered over the mesh to the database on the host device's loopback interface.
- The connection is recorded as a session and is closed when the rule's maximum duration is reached.
Registering a database (admin)
A database resource declares where a database lives — a host device and a port — so the gateway knows what to broker. It carries no credentials.
- Go to Databases in the dashboard and click Add database.
- Fill in the form:
| Field | Description | Example |
|---|---|---|
| Name | A unique name members will connect by | db-prod |
| Engine | PostgreSQL, MySQL, MongoDB, or Redis | PostgreSQL |
| Host device | The org device the database runs on | a registered mesh peer |
| Target address | The address the gateway dials on the host — loopback only | 127.0.0.1 |
| Port | The port the database listens on (defaults to the engine's standard) | 5432 |
Selecting an engine pre-fills the standard port (PostgreSQL 5432, MySQL
3306, MongoDB 27017, Redis 6379); you can override it.
The target address must be a loopback address — the database has to be
reachable on the host device's own localhost (127.0.0.1). The
gateway brokers connections to the host device and then dials loopback
there; it does not reach databases listening on a separate mesh address.
The dashboard hints when you type a non-loopback value, and the backend
rejects a non-loopback target on save.
A registered database appears in the list with its engine, host device, target, and an Active / Inactive status. Setting a database to Inactive stops the gateway from brokering new connections to it.
Access rules (admin)
A database is unreachable until an access rule grants someone access. Rules follow the same source/destination model as Meshr's SSH access rules, trimmed to what databases need.
Open Databases → Access rules and click New rule:
| Field | Description | Example |
|---|---|---|
| Name | A descriptive name for the rule | eng-can-read-orders |
| Source | A user or a group who may connect | Engineering group |
| Destination | A single database, or All databases in the org | db-prod |
| Max session duration | How long the gateway keeps connections open | 8 hours |
| Enabled | The rule grants access only while enabled | On |
- All databases is an exclusive destination that covers every current and future database resource in the org — selecting it clears any single database pick.
- Duration presets are 1 hour, 2 hours, 4 hours, and 8 hours. When the limit is reached, the gateway closes the connection.
- Each rule has an inline toggle in the rules list, so you can disable a grant without deleting it.
Access is default-deny: a user can reach a database only if a matching enabled rule grants it.
Connecting (members)
Members connect with the meshr CLI. The mesh agent must be running and
you must be logged in (meshr login).
See what you can reach
meshr db list
NAME TYPE STATUS
db-prod postgres active
If the list is empty, ask an admin to grant you a database access rule.
Open a connection
meshr db connect db-prod
Brokering 'db-prod' (postgres) on 127.0.0.1:5432
Point your client at 127.0.0.1:5432 — press Ctrl-C to stop.
meshr db connect opens a local listener on 127.0.0.1. By default it
uses the engine's standard port; pass --local-port to choose another
(for example, if that port is already in use locally):
meshr db connect db-prod --local-port 6000
Leave the command running for as long as you need the connection, then press Ctrl-C to close it.
Point your client at localhost
In another terminal, connect your normal database client to the local address — you supply the database credentials yourself; Meshr never sees them:
# PostgreSQL
psql -h 127.0.0.1 -p 5432 -U app orders
# MySQL
mysql -h 127.0.0.1 -P 3306 -u app orders
# Redis
redis-cli -h 127.0.0.1 -p 6379
# MongoDB
mongosh "mongodb://127.0.0.1:27017"
Review your sessions
meshr db sessions
STATUS STARTED DURATION IN OUT
completed 2026-06-21T09:14:02Z 742s 18234 90512
active 2026-06-21T10:02:55Z 37s 512 1208
Admins can add --all to see every brokered session across the
organization.
Audit
Every brokered connection is recorded. Open Databases → Sessions in the dashboard to review them:
| Column | What it shows |
|---|---|
| User | Who opened the connection |
| Database | Which registered database was reached |
| Status | Active, Completed, or Terminated |
| Started | When the session began |
| Duration | How long it ran (live for active sessions) |
| Transfer | Bytes received and sent |
| From | The client IP the connection came from |
Members see their own sessions; admins see the whole organization's feed and can export the filtered view as CSV. When an access rule's maximum session duration is reached, the gateway closes the connection and the session is marked accordingly.
Limitations (MVP)
- Loopback only. A database must listen on its host device's own
127.0.0.1. Databases that listen on a separate mesh address are not supported yet. - Connection-level audit. Sessions record who connected, to which database, for how long, and how many bytes moved — not the individual queries run within a session.
See also
- SSH Access Rules — the source/destination model database rules are based on.
- JIT Access — time-boxed, approval-backed access for SSH today, built to extend to more resource types.
- Zero-Trust — the security model behind brokered, default-deny access.