Skip to content
xecret
Sign in

Personal overrides

Use your own value for one secret on your machine — a local database instead of staging's — without changing the environment anyone else reads, or any CI run.

Updated 2026-10-21 · read this page as markdown

On this page

A personal override is your value for one secret in one environment. When you run xecret run, it replaces the shared value on your machine and nowhere else. It is on the Pro plan and above.

Setting one

bash
printf '%s' "postgres://localhost:5432/app" | xecret overrides set DATABASE_URL -
xecret overrides list
xecret run -- npm run dev

run prints which overrides it applied — names only — every time, so a local value is never mistaken for the shared one. Remove one with xecret overrides unset DATABASE_URL. The dashboard's environment page has a My overrides card that does the same.

The name need not be a secret the environment already holds: an override is also how you try a new variable locally before proposing it.

The rules

  • Never visible to another member. It is encrypted under a key derived from your own vault, not under the environment's key, so a teammate who can read every value in the environment still cannot open your override. Neither can the server.
  • Never forged. The same key is the only one that can make an override your CLI will accept, so a value cannot be slipped into your process in your name — not by a teammate, and not by the server. What a misbehaving server could do is keep handing back an override of yours it should have forgotten — the value you replaced, or one you removed — because an override carries no version your CLI could check. It can only ever be a value you set yourself, for that same name and environment; the trust model lists it among what xecret does not protect you from.
  • Never part of a CI fetch. A service token is refused every override route and no pull or bundle carries one: a pipeline always gets the shared values. A personal override that changed a production deploy would be the worst bug this product could have, so it is not a setting, it is the design.
  • Never inherited. An override belongs to exactly one environment; a child environment does not see its parent's.
  • Only run applies them. xecret pull and xecret export produce files that get committed and shared, which is the wrong place for one person's values. Each says on stderr when you have overrides it did not include.

After a vault reset

A vault reset gives your account a new key pair, and an override made under the old one no longer opens. xecret run stops rather than quietly using the shared value in its place — you set the override precisely so as not to get that value — and names the xecret overrides unset that removes each one. Set them again afterwards.

Offline

Overrides are fetched live, never cached. A run from the offline cache uses the shared values and says that it did.

If your plan changes

Overrides you already have keep working, and you can always list and remove them. Only setting a new one needs the plan.

Next