Privacy policy

1.Who we are, and what this covers

xecret is a secret-management service operated by Playxoft ([Playxoft legal entity name and company registration number], of [Playxoft registered address]). Playxoft is the controller for the personal data described below, and “we” means Playxoft throughout.

This policy covers the hosted service we run, this website, the documentation, and the CLI when it talks to our servers. It does not cover a xecret server that somebody else runs — see section 13.

It sits alongside two documents that say the same things in more detail: what xecret can and cannot see, and the audit log. Where this page summarises the encryption model, those pages are the longer answer, and they agree with each other because they are edited together.

2.What we collect

By category, because a paragraph of adjectives is not a disclosure.

• Account identity. Your email address, whether it has been verified, and the identifier WorkOS issues for your account. If WorkOS holds a name or a profile picture for you — as it does when you sign in with Google, which supplies both — we receive the name and the picture’s URL too. We never see your password, and never receive your Google password: a password is entered on a sign-in page hosted by WorkOS, or on Google’s own for a Google account, WorkOS verifies who you are once, and xecret issues its own session afterwards. Accounts created before we moved to WorkOS also still carry the identifier our previous identity provider, Firebase, issued them.
• Structure. The names and slugs of your organisations, projects and environments, their settings, who is a member of what, each member’s role, and per-environment access grants.
• Secret values. Encrypted, one ciphertext per version, with the version history that lets you roll one back. Section 3 states exactly what that encryption protects.
• Secret names and metadata. The name of a secret, its versions, when each changed and who changed it. These are not encrypted the way values are. A name like STRIPE_LIVE_SECRET_KEY tells us — and anybody holding the database — what you keep, though not what it is.
• Audit records. Who read, wrote, revealed or deleted what, and when, plus every denial: actor, action, outcome, resource, timestamp and a fixed set of metadata fields. No audit record can contain a secret value — the type describing that metadata is an allowlist of field names with no catch-all, so the compiler rejects an attempt to put one there.
• Sessions and devices. For each browser session: its IP address, its user agent, when it was created, when it was last seen, when it expires, when its PIN was last accepted, how it signed in — password, Google, or which organisation’s single sign-on — and the sign-in provider’s own session identifier, so that signing out here can end that session too. The session token itself is stored only as a hash, so a database dump yields hashes rather than usable sessions. If you reset your vault, the session you signed in again with also records when that sign-in happened, when a code was last emailed and how many were requested, and how many codes were tried — never a code itself, and the proof it leads to only as a hash. That record belongs to the session and is removed with it; it stops counting for anything ten minutes after the sign-in.
• Token metadata. For each CLI or service token: its name, its prefix, its scope, who created it, and when it was created, expires, was last used and was revoked. The token value is stored as a hash and shown to you exactly once.
• Membership, and its end. Which organisations your account belongs to and your role in each. When an organisation removes you, a record that you were removed — by whom and when — is kept, so that its single sign-on cannot silently re-admit you. Accepting a fresh invitation clears it.
• Billing, for a paid plan. The organisation’s plan, billing period, seat count, currency and billing country, the dates of the current period, the identifiers Dodo Payments issues for its customer record and its subscription, and a count of secret fetches per period. We never see or store a card number; Dodo holds the card.
• Your PIN, as a hash. Plus the failed-attempt counter and lockout state that stop it being guessed. We cannot recover a PIN; a reset link goes to the address on the account.
• Request logs. Method, path, a request identifier, Cloudflare’s ray id, the IP address, the user agent, and a stable event key such as secret.reveal. A field whose name suggests a credential is never serialised, and connection strings and authorisation headers are scrubbed out of message text by pattern.
• Mail we send. A PIN reset link; organisation invitations to the address you type; and, when you reset your vault, your vault archive — your secrets, still encrypted, with the names of your organisations, projects, environments and secrets in plain text — attached to a message to your own address, or a notice in its place if you chose to reset without it. On a paid plan, an organisation’s owners also receive its billing emails — a trial ending, a payment that failed, a renewal coming up, a seat change, a receipt being ready. WorkOS also sends, on our behalf, the mail that belongs to signing in: a message to verify your email address, a password reset link when you ask for one, a one-time sign-in code if you choose to sign in by email, and the one-time code that confirms a vault reset. That is the whole of it: no newsletter, no product marketing, and no tracking pixel in the mail we send ourselves.

There is no analytics on this site. No page-view tracker, no session recorder, no advertising pixel, no fingerprinting script. If that ever changes, this paragraph is the first thing that changes with it.

3.What our encryption protects, and what it does not

xecret uses server-side envelope encryption. Every environment has its own data key; that key is encrypted under its organisation’s key, which is itself encrypted under a root key we hold in a Cloudflare Secrets Store binding the database has no access to. Values are AES-256-GCM, and each ciphertext is bound to its exact position in that hierarchy — a row copied from staging into production does not decrypt.

Decryption happens inside a single request handler, and every decryption writes a row to an append-only audit log that the application’s own database credentials cannot alter. An audit row therefore means a plaintext actually left the server.

Which means xecret can technically decrypt your secret values. It is the same model Doppler uses, and it is what makes team sharing, CI tokens and browser-side .env import work without a key-exchange ceremony. We do not call xecret zero-knowledge or end-to-end encrypted, because it is neither.

What is not encrypted the way values are: the names of your secrets, organisations, projects and environments; membership, roles and access grants; audit metadata; and everything in the request logs. Those are readable by us and by anybody who obtains the database. The values are not.

If you need a provider that cannot read your secrets even in principle, you need a zero-knowledge product, and we would rather you knew that now than after migrating. What xecret can and cannot see sets out the full key hierarchy and what each kind of compromise yields.

4.Why we process it, and on what basis

Under the GDPR and the UK GDPR, each thing above rests on one of these:

• Performance of a contract (Article 6(1)(b)) — running the service you signed up for: authenticating you, storing and returning your secrets, delivering an invitation to somebody you invited.
• Legitimate interests (Article 6(1)(f)) — security and abuse prevention, and keeping the service working: rate limiting, session and token records, request logs, and the audit trail. On a secrets product the audit trail is the interest: an organisation that cannot tell who read a credential cannot respond to an incident.
• Legal obligation (Article 6(1)(c)) — records we are required to keep, and responses to lawful requests.
• Consent, where the law requires it. Today nothing here relies on it, because there is no marketing mail and no advertising or analytics cookie to consent to.

Two roles, and the distinction matters. For your account data we are the controller. For what you put into xecret — secrets, names, structure, and the audit records about them — we act as a processor on the instructions of the organisation that owns it, and that organisation is the controller. A standard data processing agreement will be published before general availability; until then, ask for one through the repository.

We do not use your data to train models. We do not profile you, we do not enrich your account from third-party data sources, and we make no automated decision that produces a legal effect for you.

5.Who else processes it

The hosted service runs on these, and on nothing else:

• Cloudflare — hosting, the Workers runtime that serves every request, the edge network, rate limiting, and the Secrets Store binding that holds the root key.
• Neon — the managed PostgreSQL database that holds everything in section 2. A self-hosted deployment can use any PostgreSQL.
• WorkOS, Inc. — identity only. It hosts the sign-in page, checks your password if you use one, and verifies who you are, so it sees your email address, your name and your sign-in events, including the IP address and browser each one came from. It also sends the sign-in mail listed in section 2. It never receives a secret or anything else you store in xecret. Once it has verified you, xecret issues its own session and keeps none of the tokens WorkOS issues.
• ZeptoMail (Zoho) — transactional email: PIN reset links, organisation invitations, the billing emails an organisation’s owners receive on a paid plan, and the vault archive or notice sent when you reset your vault. The archive passes through it as an attachment: encrypted values it cannot read, and names in plain text.
• Better Stack — log shipping, when a deployment is configured for it. When it is not, request logs stay in Cloudflare’s own tail.
• Dodo Payments — payments, as the merchant of record, for an organisation that buys a paid plan. It takes the payment, charges the tax and issues the invoice, so it receives the name, email address and billing country of the owner who checks out, and it holds the card: the card number is entered on its checkout and never reaches xecret. We send it the organisation’s id, the seat count and, past the included allowance, a count of secret fetches. It never receives a secret or anything else you store in xecret.

We will list a new sub-processor here before it starts processing anything.

If you run xecret yourself, this list is not yours. Your sub-processors are whoever you chose to host the Worker, run the database, verify identity and relay mail — the self-hosting guide names the ones the software needs.

6.How long we keep it

• Audit records — 7 days on Free, 30 days on Pro, 180 days on Team, a year on Enterprise, and whatever an Enterprise agreement states above that. A single audit query returns at most a 90-day window, which is a limit on the query and not on the retention.
• Secrets — for as long as the environment exists. Deleting a secret soft-deletes it: the ciphertext and its earlier versions stay, so that the audit record still refers to something real and so a rollback remains possible. They go when the environment, project or organisation is purged.
• Soft-deleted records — purged [Playxoft purge window for soft-deleted organisations, projects and secrets] after deletion.
• Reset vaults — when you reset your vault, the old one is kept for seven days so that you can recover it, and nothing in xecret can delete it in that window — not you, and not us through the product. It is purged automatically within about an hour after the seven days end. The archive emailed at the reset is a copy in your mailbox, and stays there for as long as you keep it: we cannot delete mail we have sent.
• Closed accounts — deleting your account revokes every session and CLI token, deletes your PIN, removes you from the organisations you are not the last owner of, and soft-deletes the organisations that were only yours. The user record itself is soft-deleted rather than erased, because the audit records you made have to keep meaning something; the actor’s label was written into each record at the time, so the log still reads correctly with the account gone. A vault you reset in the last seven days is kept until its window ends, then purged as above. Ask us if you need the identity record erased outright.
• Sessions — 30 days from creation, and immediately on sign-out or on “sign out everywhere”.
• Request logs — kept only as long as they are useful for debugging and abuse control, by whichever log sink the deployment uses. They are not used to build a profile of you.

Backups keep their own clock. A record deleted today can survive inside a database backup until that backup rotates — a property of every hosted database, stated here rather than left for you to assume otherwise.

7.Your rights

If the GDPR or the UK GDPR applies to you, you have the right to: get access to the personal data we hold about you; have it corrected; have it erased; receive it in a portable, machine-readable form; object to processing we base on a legitimate interest; and ask us to restrict processing while a dispute is being resolved. Where we rely on consent, you can withdraw it.

Two of those are self-service, and faster that way. Portability: xecret pull and the HTTP API export your secrets and their structure at any time, in a form another tool can read. Erasure of an account: Settings → delete account, which does everything described in section 6.

For anything else, ask through the repository — open an issue on GitHub — or at [Playxoft contact email address] once that address exists. We answer within one month, which is the period the GDPR allows, and sooner where we can. We may have to verify that you are who you say you are before acting on a request about an account.

If a request would mean writing personal information into a public issue, say so in the issue without including it, and we will give you a private channel.

If you think we have got this wrong, you can complain to the data protection authority where you live, or to [lead supervisory authority for Playxoft’s place of establishment]. We would rather you told us first.

8.California residents

We do not sell personal information, and we do not share it for cross-context behavioural advertising, as the CCPA — as amended by the CPRA — uses those words. We have not done so in the preceding twelve months, and we offer no financial incentive in exchange for personal information.

You may ask what we collect and why (section 2 is that list), ask for a copy, ask for correction, and ask for deletion. There is no “do not sell or share my personal information” link on this site, because there is nothing to opt out of. Exercising any of these rights costs you nothing and changes nothing about the service you receive.

Sensitive personal information: we do not collect it in order to infer characteristics about you. A secret value you store may contain anything you choose to put in it, which is why the value is encrypted and why every reveal is audited.

9.International transfers

Playxoft is established in [Playxoft’s place of establishment]. The sub-processors in section 5 are global companies, so your data will be processed outside the country you are in.

Where a transfer leaves the United Kingdom or the EEA, it relies on the European Commission’s standard contractual clauses and the UK international data transfer addendum, together with each provider’s own transfer arrangements. The Workers runtime serves each request from whichever data centre is nearest to the caller and stores nothing; the database that holds your data lives in one region, fixed when the deployment was created.

10.Cookies and browser storage

Six cookies, all strictly necessary, none of them a tracker:

• __Host-xecret_session — your signed-in session. HttpOnly, secure, same-site, and valid for 30 days unless you sign out. It carries an opaque token; the server stores only its hash.
• __Host-xecret_csrf — a token this site’s own JavaScript reads and echoes back, so a form on somebody else’s site cannot make a request as you. Same lifetime as the session.
• __Host-xecret_oauth_state — set when you leave for the sign-in page and cleared when you come back, so that a sign-in can only be completed in the browser that started it. HttpOnly, secure, signed, and valid for ten minutes. It holds the one-time values that tie the sign-in to your browser and the page to return you to.
• __Host-xecret_sign_in_confirm — set only when a sign-in is held back for your confirmation (“Is this you?”). It carries the held-back sign-in, sealed so that only this site can read it. HttpOnly, secure, single-use, and valid for five minutes.
• __Host-xecret_sso_continue — set when you open an organisation’s sign-in link, so that only the warning page’s own Continue button can start that organisation’s sign-in. HttpOnly, secure, and valid for five minutes.
• __Host-xecret_last_account — a signed note of which account last signed in on this browser, so we do not ask “Is this you?” needlessly when our sign-in provider remembers you. HttpOnly, secure, and valid for 180 days. It names an account id and nothing else.

The sign-in page itself is served by WorkOS, and whatever it stores in your browser is governed by WorkOS’s own policy rather than this one.

Two preferences live in localStorage on your own device and are never sent to us: xecret.theme (light, dark or system) and xecret.sidebar (whether the dashboard sidebar is collapsed).

There is no advertising cookie, no analytics cookie and no third-party tag on this site. That is why there is no cookie banner: there is nothing to ask you about. If we ever add analytics, this section will say so, and we will ask first where the law requires it.

11.How we protect it

• Secrets are AES-256-GCM under a per-environment key, wrapped up a four-layer hierarchy whose root key is never in the database.
• Session tokens, CLI tokens, service tokens and PINs are stored as hashes. A token is shown once, at creation, and cannot be re-read afterwards.
• The application’s database role cannot alter the audit table. It is append-only by grant rather than by discipline.
• Error messages returned to a client are fixed strings — never derived from an exception, a database error or the rejected input, because the rejected input may itself be a secret.
• Reveals and destructive actions sit behind a PIN lock with an idle auto-lock, so an unattended session cannot read a value.

No system is perfect, and this one is pre-alpha. If we discover a breach affecting your personal data, we will notify the affected organisation’s owners without undue delay, and the relevant supervisory authority within 72 hours where the law requires it. To report a vulnerability, follow SECURITY.md in the repository rather than opening a public issue.

12.Children

xecret is a developer tool and is not directed at children. We do not knowingly collect personal data from anyone under 16. If you believe a child has created an account, tell us and we will delete it.

13.Self-hosted deployments

The server is AGPL-3.0 and running it yourself is a documented, supported path. If you do, this policy does not govern your users: the operator of that deployment is the controller, chooses the database, the identity provider and the mail relay, holds the root key, and writes their own privacy policy.

We receive nothing from a self-hosted instance — no telemetry, no phone-home, no licence check. Self-hosting states the real dependency list, including the parts that are friction, and is blunt about the one irreversible risk: lose the root key and every secret is unrecoverable.

14.Changes to this policy

When this policy changes, the date at the top of the page changes with it. For a change that materially affects your rights, we will email the owners of every organisation and announce it in the repository before it takes effect.

This page lives in the same repository as the product, so its history is the git history: you can see what it said before, and when it changed, without taking our word for it. That is the point of publishing the source of the thing you are trusting.

15.How to contact us

There is no support email address published yet, and we would rather say that than invent one. Until [Playxoft contact email address] is live, the way to reach us about anything on this page is an issue in the repository.

Postal address: [Playxoft registered address]. Data protection officer or Article 27 representative: [none appointed — to be confirmed before general availability].

The two documents that answer most follow-up questions before you have to ask them are the trust model and the terms of service.