The questions you ask before you trust a secrets manager.

Yes, technically, and you should know that before you migrate rather than after. xecret uses server-side envelope encryption: every environment has its own data key, itself encrypted under a root key we hold, and values are decrypted inside a single request handler. Every one of those decryptions is written to an append-only audit log. This 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.

No, and we do not use those words about xecret because they would not be true. If you need a provider that cannot read your secrets even in principle — because a regulator requires it, or because your threat model includes the provider being compelled — you need a zero-knowledge product, and you should choose one now. The trust model page makes the same argument at greater length.

The attacker gets ciphertext. No key material at any layer is stored in the database: the root key lives in a Cloudflare Secrets Store binding the database has no access to. Each ciphertext is also bound to its exact position in the key hierarchy, so a secret row copied from staging to production simply does not decrypt.

The root key together with a database dump exposes everything, and that is the one scenario this model does not defend against. It is why the two are kept in different systems with no path between them. If you self-host, custody of that key becomes yours — generate it, split it, and escrow the shares before the first real credential goes in.

Every layer of the hierarchy — root, organisation, environment — is versioned, so any one of them can be rotated independently of the others. A key rotation is itself an audited event. Rotating an individual secret is just a write: the new version becomes current and the history stays readable.

Yes, and every decryption is in it, including your own. Every mutation and every denial is recorded too, because a system that logs only what succeeded cannot show you an attack in progress. The table is append-only by database grant rather than by convention — the application credentials cannot alter it.

No, and that is enforced by the type system rather than by review. The type describing audit metadata is a fixed allowlist of field names with no catch-all, so code that tries to put a value into a record does not compile. Error messages are fixed strings for the same reason: nothing derived from an exception or from rejected input reaches a client, because the rejected input may itself be a secret.

Only when you ask for it. xecret run never writes them — it hands them to your process and nothing else. xecret pull does write a file, by design, and warns on stderr every time. The CLI offline cache keeps an encrypted copy whose key lives in your operating system's keychain, not beside the file.

No. xecret is pre-alpha and holds no compliance certification of any kind, and inventing one on a secrets product would be the worst thing we could ship. What exists instead is public: the source, the threat model, the licence and the self-hosting instructions.

Not yet. It is feature-complete for its first version, but it has not run against production infrastructure and has not had an external security review. Do not put credentials you cannot afford to rotate into it today.

Privately — open a security advisory on the GitHub repository, or email security@playxoft.com. Please do not open a public issue. You get an acknowledgement within 48 hours and an initial assessment within five working days, and we credit you in the advisory unless you would rather we did not.

It works out which project and environment you are in, fetches that environment, and execs your command with the values already in its environment. Nothing is written to disk. Signals are forwarded, so Ctrl-C reaches your application rather than the wrapper.

For xecret run, yes. The CLI keeps an encrypted copy of the last environment it fetched and falls back to it when the API cannot be reached, printing the age of that copy to stderr so day-old configuration never passes silently. The first run in a given environment needs a network, because that is what fills the cache.

A DNS failure, a timeout or a 5xx falls back to the cache, loudly. A 401, 403 or 404 does not, because those are decisions rather than outages — and the most important of them is revocation, which has to take effect immediately rather than immediately-unless-the-laptop-is-offline. CI has no cache at all, deliberately.

Drag it into the import dialog. It is parsed in your browser and a dry-run preview shows exactly what will be created, renamed or skipped, so a pasted blob of production credentials never becomes a request body. The CLI has the same importer with the same dry run, and dotenv, JSON, YAML and shell formats are all detected.

Yes — xecret pull writes five different formats, and the dashboard has an export dialog. There is no export fee and no lock-in mechanism. Version history is the one thing a bulk export does not carry.

Through a service token. A service token is not a person: it is pinned to one project and one environment, it is read-only unless you deliberately make it otherwise, and it can never delete a secret at any access level. Put it in XECRET_TOKEN on the runner and your existing xecret run command works there too.

Yes. Pass --environment on each command and every process gets its own set of values, with nothing shared between them. The dashboard marks production with a reserved colour, an uppercase label and hazard hatching, so which environment you are looking at survives both a small screen and colour blindness.

Yes, and you can read all of it before you sign up for anything. The server is AGPL-3.0 and the CLI is MIT. There is no open-core arrangement where the interesting half lives in a private repository.

The AGPL means that if you modify the server and offer it to other people as a network service, you publish your changes. The CLI is MIT because it ships inside your Docker images and your CI runners, where a copyleft licence would be friction with no security benefit to anybody.

Cloudflare Workers on a paid plan, a PostgreSQL database, a Cloudflare Secrets Store binding to hold the root key, and a WorkOS account for identity. The WorkOS requirement is real friction — it is a hosted service, so even a self-hosted install relies on an outside company to sign people in — and the documentation says so rather than burying it; an identity-provider interface exists so that a Postgres-native alternative can be contributed. Mail is optional — without it, invitations become a shareable link instead of an email.

None. It is the same server that runs the hosted product, with nothing gated behind a licence check. If a feature exists, it exists for you.

You export it, or you run the server yourself, and neither path needs us to still be here. The source is published under a licence that cannot be withdrawn from the copies already released, and self-hosting is a documented path rather than a theoretical right.

Yes. That is what the licence is for. If your fork is a modified server you offer to other people over a network, the AGPL asks you to publish your changes; beyond that, go ahead.