Looking for a Doppler alternative

First: why are you looking?

The reason matters, because it decides which of the questions below you should weight. In practice teams go shopping for one of five reasons:

• Price at your size. Per-seat pricing scales in a way that surprises small teams, particularly ones with more contributors than full-time engineers.
• It is more product than you need. Dynamic secrets, rotation schedules and deep cloud integrations are real features that some teams genuinely never touch.
• The local workflow. This is the one people actually feel daily — how a secret gets from the store into the .env the app reads.
• Compliance arrived. Someone now needs an audit trail with names and timestamps on it.
• Lock-in. Whatever you pick, you should be able to leave with your data.

If your reason is dynamic secrets, short-lived database credentials, or a Kubernetes operator, stop reading — Sink does not do those, and the rest of this page will not change that.

The questions worth asking

How is a secret actually encrypted?

"Encrypted at rest" is close to meaningless on its own — it can mean full-disk encryption on the database host, which protects against a stolen drive and nothing else. The question to ask is what the unit of encryption is, and where the key that unlocks it lives.

Sink uses envelope encryption. Every secret gets its own AES-256-GCM data encryption key; that key is itself encrypted under the deployment's master key before anything is written. Neither the plaintext value nor the raw data key is stored. The practical consequence is blast radius: one compromised ciphertext is one secret, not the whole table.

Can access be scoped the way your team is actually shaped?

Most teams need at least the distinction between "can read development" and "can read production". A tool that only has members and admins forces you to choose between over-granting and not using it.

Sink organises secrets as Workspaces → Teams → Projects → Environments, with four roles — Viewer, Member, Admin, Owner. Environments are isolated from each other, so development genuinely cannot see production's values rather than merely being discouraged from looking.

What does the audit trail contain?

Ask whether reads are logged, not just writes. A log that records changes but not access answers the wrong half of "who has seen this credential?"

In Sink every create, read, update, delete and share is written to the audit log with the member and a timestamp. Secrets are versioned as well: each update mints a new version and the old ones stay readable, which is what makes sink pull --version 3 a way to answer what a value used to be.

What is the local developer workflow?

This is the question that decides whether the tool gets used or quietly routed around. If getting a secret into local development takes more than one command, someone will keep a .env on the side, and the store stops being the source of truth on the day that happens.

sink login          # API key into the OS keychain
sink init           # writes .sink.json — ids only, safe to commit
sink pull           # writes .env, 0600
sink diff           # how local differs from the environment
sink push           # send local changes up

The committed .sink.json is the part that matters for onboarding: a fresh clone already knows which environment it belongs to, so a new hire runs sink pull and is done, and nobody has to send a file to anyone.

How do you get your data out?

Ask this before you migrate in, not after. For Sink the answer is sink pull --format json for a whole environment, or the REST API, which is the same API the CLI uses — there is no export-only subset.

What happens when the service is down?

A secret manager is on the critical path for deploys, and sometimes for start-up. Worth knowing what your fallback is for both — for most teams the honest answer is a recently pulled .env and a documented break-glass procedure, and it is better to decide that deliberately than at 3am.

Where Sink fits

Sink is deliberately small. It is a hosted secret manager for development teams that want encryption, roles, versions and an audit trail without adopting a platform. It is a good fit when:

• Your secrets are environment variables, and your applications read them from the environment or a .env.
• You want the local workflow to be one command, and to keep working the same way in CI with SINK_API_KEY.
• You are moving off a shared .env, a password manager entry, or a pinned Slack message, and want the smallest step that is genuinely better.
• You need to show someone an audit trail without a procurement cycle.
• You are already on Railway, Vercel or Render — sink import pulls straight from all three, so the first migration is one command rather than an afternoon.

Where it does not

Being specific about this is more useful than another tick in a table:

• No dynamic secrets. Sink stores values you give it. It does not mint short-lived database credentials on demand.
• No automatic rotation. Rotation is a thing you do — in the provider, then in Sink — not something it schedules for you.
• No Kubernetes operator, no Terraform provider as of this writing.
• Hosted only. There is no self-hosted distribution today, so if your requirement is that secrets never leave infrastructure you control, this is the wrong tool and you likely want Vault or an open-source manager you can run yourself.
• Public beta. Worth weighing honestly against how much the thing you are storing would hurt to lose.

Trying it against what you already have

The cheapest evaluation is to import a real environment and use it for a week — a dry run changes nothing and shows you exactly what would land:

sink login
sink init
sink import vercel development --project my-app --dry-run

Railway and Render work the same way; there are step-by-step guides for Vercel, Railway and Render. Provider tokens are used for that one request and never stored.