Proxified Connections #

By default, database credentials live in datasource.config.json on your machine. Proxified connections store them encrypted on the server instead.

When to use #

Use proxified connections when:

• Your team shares databases and credentials should not live on individual machines
• You need a single managed connection pool shared across developers, rather than each client opening its own connections against the database

Enabling #

Check Proxy connection in the connection form. The DSN and SSH fields are sent to the server and stored encrypted. The local datasource.config.json only keeps the dialect and the ID. The name is the folder the database lives in, as it is for any database.

Once configured, credentials never leave the server. Users do not see or receive the DSN or SSH secrets. All database connections are established and maintained on the remote server, and queries are proxied through it.

Permissions are not optional here #

A local connection with no permission rules is open: the DSN is yours and you are querying your own database. A proxified one is the opposite. The credentials are ours to hold and the query runs on our server, so a database that no role grants access to is refused for everyone, including the person who added it.

Adding a proxified datasource is therefore two steps: create the connection, then give a role an allow rule for it.

Connection pool #

Proxified connections expose pool tuning:

Setting Max open conns too high can exhaust your database’s connection limit. Start with the default and adjust based on team size.

Limitations #

• Environment variable substitution ($VAR_NAME) is not supported in proxified mode
• Credentials are managed server-side, so local .env files have no effect on the connection