Projects and environments

Two levels, deliberately. Deeper hierarchies invite a week of configuration before anyone stores a secret.

A project is usually one codebase, and it is the unit of membership: you invite people to a project.

An environment lives inside a project and holds the actual entries. Conventionally dev, staging, production, but the names are yours. An environment is the unit of access and the unit of encryption — it has its own key, and access is granted per environment.

That split is the whole design. Being a member of a project gets you nothing on its own; it makes you addressable. What you can read is decided per environment.

Creating an environment

Three things happen on your device, in this order:

1. A fresh encryption key for the environment is generated from the OS CSPRNG.
2. That key is wrapped to your own public key and uploaded — the wrapped blob is opaque to the server.
3. An encrypted empty payload is written as version 1.

The order matters. Because a first payload always exists, any device that later receives a wrapped key has something authentic to verify it against before trusting it. An environment with a key and no payload would be a key nobody could check.

Production is treated differently

Amber, everywhere it matters: the environment tab, context labels in dialogs, and any confirmation involving it.

The colour is never the only signal. A production environment also carries a shield glyph and, of course, its name — so the distinction survives for a colour-blind reader, in a grayscale screenshot, and in a terminal.

Amber is reserved for exactly this and for “this needs your attention”. It is never decorative anywhere in the product, including on this website, because a colour used for emphasis stops meaning danger.

Ordering

Environment tab order is a project-wide setting, dragged into place once. It is shared across the team, so everyone sees the same order — which is the point, since “the first tab” becomes shorthand in conversation.

Deleting

Deleting an environment destroys its key and payload. There is no undo, and no copy on our side to restore from.

An environment that is created but never used — no grants, no payload — is cleaned up server-side after an hour’s grace, so an abandoned half-created environment doesn’t linger.

What the server knows

This is metadata, and it is not encrypted:

• Your account email
• Project and environment names, and their display order
• Payload sizes and version counts
• When each environment was read or written, and by whom

Content is opaque. Existence and activity are not. So an environment named acme-prod-stripe-live tells the server something even though every value inside it is unreadable — name things with that in mind if it matters to you.

Encrypting names was considered and rejected for now: it makes invitations and administration meaningfully worse for a modest gain, since sizes and timing would still leak. It’s the kind of decision worth revisiting later, and the threat model lists it as an accepted limitation rather than pretending it away.