Skippr Docs

Appearance

How to Manage MotherDuck Destination Credentials in Skippr ​

July 2026

Keep MotherDuck destination credentials safe by moving the token into MOTHERDUCK_TOKEN, leaving database and schema visible, and granting the token write access only to the landing area Skippr uses.

Short Answer ​

Manage MotherDuck destination credentials in Skippr by keeping database and schema in config and loading motherduck_token from ${MOTHERDUCK_TOKEN}. The docs do not ask you to hide the database name. They ask you to keep the token itself out of skippr.yaml.

That token choice affects both regular loads and CDC behavior. Once the token can write to the selected database and schema, Skippr can load data and, when CDC is enabled, apply the documented DuckDB MERGE-based final-state logic with _skippr_order_token and tombstone tables.

Why Teams Struggle with This ​

MotherDuck credential handling usually goes wrong in ordinary ways: a token gets pasted into config, shared between environments, and left broader than the destination schema actually needs. The docs give you a simpler model than that.

  • A literal MotherDuck token in config is a direct secret leak.
  • Sharing one broad token across development, staging, and production makes revocation and auditing harder.
  • The database and schema should stay visible because they define where the warehouse tables land.
  • If the runner does not have outbound network access to MotherDuck, changing the token will not restore the load path.

How Skippr Handles It ​

Skippr keeps the MotherDuck destination easy to reason about because the auth surface is just the token, while the warehouse target stays visible and reviewable. That is a good fit for small teams that want a narrow destination contract.

It also keeps CDC expectations concrete. The same token that lands the table can support the documented final-state merge behavior without requiring a second credential system.

  • Uses motherduck_token: ${MOTHERDUCK_TOKEN} for authentication.
  • Keeps database and schema visible as ordinary destination config.
  • Fits a token scoped to the exact MotherDuck database and schema Skippr uses.
  • Supports CDC final-state reconciliation through DuckDB MERGE, order tokens, and tombstone tables.

What the First Useful Version Looks Like ​

The first useful version is one MotherDuck database, one schema such as main, and one token that can create and write objects there. That is enough to prove the destination contract before you add more pipelines.

If you later separate environments, keep the database names explicit and rotate tokens per environment rather than reusing one shared token everywhere.