Export & import credentials

functional

Move servers, databases, logins and their passwords - plus label colors and icons - between machines in one file, picking exactly which servers and databases to include.

A credential file moves a whole working setup between machines or teammates in one step: servers, the databases on them, the logins to use, and their passwords, together with the client, project, and environment labels those connections belong to, including each label's color and icon. Export one from SQLly, or write one by hand to provision a team, and import it on any copy of SQLly.

Passwords are in clear text. That is what makes a credential file useful - and what makes it sensitive. SQLly saves an exported file readable only by you, moves every password into your system keychain on import, and never keeps a copy of the file. Send it over a channel you trust, and delete it once it has been imported. To share connections without passwords, use File → Export Connections… instead.

Export credentials

Choose File → Export Credentials… (or run Export Credentials from the command palette). A picker shows every saved connection as a tree: each server (host, port, and engine) with the databases you have saved on it underneath.

Pick any or all servers - tick a server to take every database under it, or tick it again to clear them.
Pick any or all databases - expand a server and tick individual databases; the server row shows how many of its databases are selected.
Select all / Clear toggles everything at once. Everything starts selected.
Only what you picked comes along - the shared logins, tunnel profiles, and client, project, and environment labels the chosen connections use are included, and nothing else.

Click Export, choose where to save, and SQLly writes the file with each password read back out of your keychain. A login used by several of the exported connections is written once as a shared login; a login used by one connection is written on that connection. Label icons are embedded in the file, so it is complete on its own.

Import credentials

Choose File → Import Connections… and pick the file - SQLly recognizes a credential file on its own. Before changing anything it checks the whole file and, if any entry is wrong, lists every problem and imports nothing, so a half-applied import can't happen. A mistyped setting name is reported rather than silently skipped.

Passwords go to your keychain - Keychain on macOS, Credential Manager on Windows, Secret Service on Linux - never into SQLly's saved connections file.
Labels merge by name - an existing client, project, or environment keeps anything the file doesn't set, and only the safety switches the file lists change.
Shared logins update in place - a saved login with the same name and user name gets the new password, so every connection already using it keeps working.
No password, no problem - a login without one is imported anyway, and SQLly asks for the password the first time you connect.

What a credential file can hold

Section	What it carries
Connections	Any number of servers and any number of databases on each: engine, host, port, database, environment, client and project, sign-in method and password, TLS mode and certificate files, connect and statement timeouts, application name, startup SQL, per-connection safety switches, favorite star, masking rules, relay route, and an inline SSH tunnel, proxy, or Kubernetes port-forward.
Shared logins	Several named user name and password pairs that many connections can use.
Tunnel profiles	Named SSH (with jump host), proxy, and Kubernetes chains, including SSH passwords and key passphrases.
Clients, projects, environments	Name, color, icon image (embedded in the file), and any of the query protections.

Every sign-in method SQLly supports can be described: user name and password, Windows integrated security, Microsoft Entra (browser or device code), AWS RDS IAM, Google Cloud SQL IAM, and libSQL / Turso tokens. SQLite and DuckDB files need no sign-in.

Writing one by hand

A credential file is plain JSON, so an admin can write one to hand a team a ready-made setup. Only a connection's name, engine, and server are required - everything else falls back to the same default the connection editor uses. This file adds two databases on one server that share a read-only login, a second server with its own password, and a colored client with an icon:

{
  "format": "sqlly-credentials",
  "version": 1,
  "clients": [
    { "name": "Acme", "color": "#1E88E5", "image": "data:image/png;base64,iVBORw0KGgo…" }
  ],
  "sql_auth_accounts": [
    { "name": "Reader", "username": "ro", "password": "ro-secret" }
  ],
  "connections": [
    { "name": "Sales", "engine": "postgresql", "server": "pg1.acme.internal", "database": "sales",
      "client": "Acme", "environment": "production",
      "authentication": { "type": "sql-login", "account": "Reader" },
      "tls": { "mode": "verify-full" } },
    { "name": "HR", "engine": "postgresql", "server": "pg1.acme.internal", "database": "hr",
      "client": "Acme", "authentication": { "type": "sql-login", "account": "Reader" } },
    { "name": "Ops", "engine": "sql-server", "server": "sql01.acme.internal", "database": "ops",
      "authentication": { "type": "sql-login", "username": "ops", "password": "ops-secret" } }
  ]
}

Engines can be written loosely - postgres, PostgreSQL, mssql, sql-server, mysql, sqlite, duckdb, clickhouse, redis, and so on.
Colors are #RGB, #RRGGBB, or #RRGGBBAA.
Icons are base64 - a data:image/…;base64, URI or the bare base64 - of a PNG, JPEG, GIF, WebP, BMP, ICO, or SVG image up to 1 MB.
Environments are local, dev, test, staging, or production.