How to migrate from Doppler

Pick a token

A personal token can see every project you can, so the CLI will offer you a list to pick from. A service token is scoped to one config, which means it cannot list anything — name the project and config yourself in that case. Either works; the service token is the tighter of the two.

sink login
sink init                       # writes .sink.json — ids only, safe to commit

export SINK_DOPPLER_TOKEN=dp.pt....
sink import doppler production --dry-run

With nothing else specified the CLI prompts through the projects and configs the token can see. To skip the prompts:

sink import doppler production \
  --project my-app \
  --provider-env prd

What comes across

Every key in the config, with the value Doppler computes — so a secret referencing another secret arrives resolved, the way your application would have seen it. Doppler's own DOPPLER_* variables are left behind: they describe Doppler, not your application. Dynamic secrets are excluded too, since a minted-per-request credential would be stale the moment it landed.

One config at a time. Run the import once per environment:

sink import doppler development --project my-app --provider-env dev
sink import doppler staging     --project my-app --provider-env stg
sink import doppler production  --project my-app --provider-env prd

Before you switch over

• Run each import with --dry-run first and read the diff.
• Existing keys are skipped unless you pass --mode overwrite, which mints a new version rather than discarding the old value.
• sink pull into a scratch file and start your app against it before you retire the Doppler config.
• Revoke the Doppler token when you are done.

If you would rather not re-paste the token each time, a workspace admin can save it: sink connections add doppler "Doppler", then sink import --connection Doppler production. It is stored encrypted server-side and revocable from Settings › Connections.

There is also a longer comparison of Doppler and Sink if you are still deciding.