Legal

Privacy
Policy.

Sink is a secrets manager. The whole product is built around holding a small amount of data very carefully, so this policy is specific about what we hold, where it sits, and who else can touch it.

Effective 15 August 2026
Last updated 15 August 2026

1. Who we are

Sink ("Sink", "we", "us") is operated by Benjamin Lawani. We provide a hosted secret management service at usesink.co, together with a command line client and API.

For data protection purposes we are the controller of the account and usage data described below, and a processor of the secrets and configuration you store in your workspaces on behalf of your organisation.

2. Scope

This policy covers the hosted Sink service, the marketing site, the dashboard, the API and the CLI. It does not cover self-hosted deployments of Sink that you run on your own infrastructure — see section 12 — nor third-party services you connect to Sink, which are governed by their own policies.

3. What we collect

Account data

  • Your name and email address.
  • A bcrypt hash of your password, if you sign up with one. We never store the password itself.
  • A one-time verification code and its expiry, during signup and email verification.
  • Where you sign in with Google or GitHub: the provider, your provider account id, the email on that account, and the OAuth tokens the provider issues us.

Session and credential data

  • Sessions, each holding a refresh token, the IP address and user agent the session was created from, its expiry, and whether it has been revoked.
  • API keys you create: their name, optional description, expiry, and the time each was last used.

Workspace content

  • Names and structure of your workspaces, teams, projects and environments, and the membership and role of each member.
  • Secret names and optional descriptions, in plaintext — we have to index and display them.
  • Secret values, encrypted (see section 4), along with the full version history of each secret.
  • An audit log recording which member performed which action against which secret, and when.
  • Rotation policies, where configured.
  • Invitations you send, including the invited email address.

Share links

When you create a share link, the selected secret ids, the member who shared them, a view limit and an expiry are written to our Redis cache under a random token and deleted automatically when the link expires or its view limit is reached. Anyone holding the token can redeem the link — that is what makes it shareable — so treat the URL itself as sensitive.

Billing data

Payments are handled by our payment processor, Bachs. We store your plan, subscription status and the customer identifier Bachs assigns you, plus invoice records. Card numbers and payment credentials never reach Sink's servers — they are entered on the processor's hosted checkout.

Connected integrations

If you import environment variables from Railway, Vercel or Render, you supply an API token for that provider. We use it to list your projects and read the variables you select for import, and for nothing else.

Technical and usage data

  • Request logs and traces: method, path, status code, timing, a trace id, and the IP address and user agent of the request. These go to our observability provider, Logfire.
  • Error details, including stack traces. Error responses returned to you are written by hand and never echo an exception, so internal details are not leaked in the response body.
  • Rate limiting counters keyed to your account or IP address.

We do not run advertising trackers, and we do not sell personal data or share it for cross-context behavioural advertising.

4. How secrets are held

Every secret value is envelope encrypted before it is written to the database. Each version of each secret gets its own randomly generated AES-256-GCM data key; the value is encrypted under that data key, and the data key is itself encrypted under a master key held in the application's environment, never in the database. What the database holds is ciphertext, a nonce, and a wrapped data key.

To be plain about the trade-off: this is not end-to-end encryption. The hosted service decrypts values in memory to serve them to you, your CLI and your integrations, which means Sink is technically capable of reading them. Access to the master key and to production systems is restricted to personnel who need it. If your threat model requires that no operator can ever read your values, self-host Sink and hold your own master key.

5. How we use data

  • To run the service — authenticate you, enforce roles and permissions, store and serve secrets, and honour rotation and sharing rules.
  • To keep it secure — detect and block credential stuffing and abuse, rate limit, and investigate incidents.
  • To bill you — apply plan limits and entitlements, and process subscriptions.
  • To communicate — transactional email such as verification codes, invitations, and service notices. We do not send marketing email without consent.
  • To improve it — aggregate performance and error analysis.
  • To meet legal obligations — tax, accounting, and lawful requests.

We do not use your secret values or workspace content to train machine learning models.

Where the GDPR, UK GDPR or a comparable law applies, we rely on: performance of a contract for account, workspace and billing data; legitimate interests for security, abuse prevention and service improvement; consent where we ask for it, which you may withdraw at any time; and legal obligation for records we are required to keep.

7. Who we share with

We share data with a short list of infrastructure providers who process it on our instructions and under contract. They are named individually, with what each one processes and where, on our Subprocessors page.

Beyond those, we disclose data only: to other members of your workspace, as the roles you configure dictate; to a provider you explicitly connect; where you direct us to; where required by law, after reviewing the request; and to an acquirer in a merger or acquisition, under this policy's terms.

8. Where data lives

The application runs in Johannesburg, South Africa. The primary database is a managed PostgreSQL instance in London, United Kingdom (AWS eu-west-2). Email, payments, file storage and observability are handled by the providers listed on the Subprocessors page, in their own regions.

This means personal data is transferred internationally. Where those transfers leave the EEA or UK, they are made under Standard Contractual Clauses or an equivalent transfer mechanism in our agreements with each provider.

9. Retention

  • Account data — for as long as your account exists.
  • Secrets, versions and audit logs — until you delete them, or until your account is deleted. Deleting a workspace cascades to its teams, projects, environments and secrets.
  • Sessions — until expiry or revocation.
  • Share links — until the expiry or view limit you set, at which point the cache entry is removed.
  • Logs and traces — retained by our observability provider on a rolling window of 30 days.
  • Billing records — for as long as tax and accounting law requires, typically 3 years.

On account deletion we remove your account and workspace content within 30 days, excluding records we are legally required to keep and backups, which age out on their own schedule.

10. Your rights

Depending on where you live, you may have the right to access, correct, delete, export or restrict the processing of your personal data, to object to processing based on legitimate interests, and to withdraw consent. Much of this you can do yourself from the dashboard; for the rest, write to [email protected] and we will respond within 30 days.

If you are in the EEA or UK you may also complain to your local supervisory authority. We would appreciate the chance to resolve it first.

If you use Sink through an employer's workspace, your employer controls that content; we will refer requests about it to them.

11. Security

  • Envelope encryption of secret values, as described above.
  • Passwords hashed with bcrypt; API keys and refresh tokens stored so they cannot be read back.
  • TLS enforced on all connections, including to the database.
  • HttpOnly, Secure, SameSite refresh cookies.
  • Role-based access control at workspace, team and project level.
  • Rate limiting on authentication, share redemption and other sensitive routes.
  • Error sanitisation, so responses never leak schema or driver detail.
  • An audit trail of secret access and modification.

No system is perfectly secure. If you believe you have found a vulnerability, please report it to [email protected] rather than disclosing it publicly. Where a breach affecting your personal data occurs, we will notify you and the relevant authority as the law requires.

12. Self-hosting

If you run Sink on your own infrastructure, your deployment sends us nothing and this policy does not apply to the data inside it. You are the controller of that data, you hold the master key, and you choose your own database, cache, email and observability providers.

13. Children

Sink is a developer tool and is not directed at children. We do not knowingly collect data from anyone under 16. If you believe a child has given us data, contact us and we will delete it.

14. Changes

We will update this policy as the service changes. The "last updated" date at the top always reflects the current version, and we will notify account holders by email of material changes at least 30 days before they take effect.

15. Contact

Privacy questions and rights requests: [email protected]
Security reports: [email protected]
Everything else: [email protected]