Skippr Docs

Appearance

How to Manage MSSQL Source Credentials in Skippr ​

July 2026

Keep MSSQL source credentials safe by moving the ADO.NET connection string into MSSQL_CONNECTION_STRING, using the right SQL Server encryption settings for the environment, and limiting the login to read access.

Short Answer ​

Manage MSSQL source credentials in Skippr by treating the ADO.NET connection string as the secret and keeping it in MSSQL_CONNECTION_STRING. The connector docs use one connection_string field, so the safest pattern is to reference that env var from the runtime rather than store a DSN with user id and password inside the repo.

That is more than basic secret hygiene because SQL Server auth details often include encryption behavior too. A local container may legitimately use TrustServerCertificate=true, while Azure SQL should usually use Encrypt=true with a fully qualified server name. Those choices belong in the connection string you control, not in ad hoc edits scattered across files.

Why Teams Struggle with This ​

MSSQL secrets are easy to mishandle because the full connection model lives in one string. Once that string is copied into config, tickets, or scripts, you have copied the password, host, database, and security posture all at once.

  • Checking in MSSQL_CONNECTION_STRING as a literal exposes user id and password immediately.
  • Using a broad login instead of a read-scoped login turns one source credential into a much larger database risk.
  • Keeping TrustServerCertificate=true in a production-style string can hide certificate problems you should fix instead.
  • If the SQL Server host or port is unreachable, rotating the secret will not restore connectivity.

How Skippr Handles It ​

Skippr keeps MSSQL auth simple because it does not split one SQL Server DSN across several custom fields. You provide the connection string through the environment, then the connector uses that exact SQL Server authentication context to read the selected tables.

That is also easier to operate across local Docker, self-hosted SQL Server, and Azure SQL. The article can tell readers to protect one environment variable and review one read login, instead of managing a patchwork of half-secret settings.

  • Uses a single MSSQL_CONNECTION_STRING environment variable for the secret-bearing credential.
  • Supports local SQL Server and Azure SQL with the same documented connection-string format.
  • Keeps TLS and certificate settings in the DSN where SQL Server expects them.
  • Works best with a login that only needs read access to the source tables or views.

What the First Useful Version Looks Like ​

The first useful version is one SQL Server login, one environment variable, and one table read that proves host reachability, TLS settings, and permissions are all correct.

If you are testing locally with Docker, use the development certificate shortcut only there, then move to the stricter production connection string before the pipeline becomes shared infrastructure.