On a project’s page, choose Build → Environment variables to open
Environment variables in project settings; its Env Variables/Secrets
group lists the stored entries. You can also open a branch workspace and
choose Secrets in the editor’s tools sidebar. These entries belong to the
project: workspace entries can reach the project’s other branch servers too,
not just the branch you have open.
Every entry is stored the same way, whether it holds a password or an
ordinary setting: encrypted and write-only, and delivered to its tools as an
environment variable.
Store a secret
- Choose New (in the editor’s Secrets panel, New secret).
- Enter its environment-variable name and value.
- Choose Workspace or CI; the form explains the choice under its
selector. Workspace variables go to branch servers; CI variables go to CI
runs. Choose the environment, or Every environment when that scope is
intended. CI entries can also be limited to protected branches.
- Review the scope and store the entry.
Values are write-only: the list shows names and metadata, never stored
values. Replacing an entry requires entering its new value. If environments
cannot be loaded, retry that read before creating a secret.
Paste several entries
Choose New, then Paste several inside the form (there is no separate
page action), or paste multiple
NAME=value lines into its name or value field. Review the preview before
storing. Every entry uses the selected class and environment; existing names
are marked as replacements. A paste accepts up to 100 distinct names and
1,048,576 characters; split larger inputs into smaller pastes.
Blank lines and full-line comments are ignored. export and matching quotes
are supported; a repeated name uses its last value. This is a simple line
parser, without shell expansion or multiline quoted values.
Before a batch starts, ReasonOS re-reads the list and checks it against the
list as it was when you opened the form. A detected conflict stops the batch before any entry is sent.
The batch then saves one entry at a time, checking each entry again as it
is written. If the list cannot be re-read before a batch, nothing is sent;
try again. If it stops partway through, earlier entries can already be
stored. The form names acknowledged entries and retains the draft.A lost response can leave the last entry’s outcome uncertain. Retrying keeps
the original version check; it does not silently overwrite an entry that
changed while you were working. If the earlier attempt did land, the retry
is refused as a change, and you review before storing again.
Find and update entries
Search by name or environment, and combine the search with the
Workspace or CI filter. Select an entry’s replace action to change
its value while keeping its identity and scope.
If an entry changed since you opened the form, ReasonOS refuses that write
and keeps your draft. Storing stays unavailable until you choose
Review changes to refresh the preview and version checks before deciding
whether to store again. Review updates which entries will be replaced;
stored values are never shown.
Navigating to another project starts a fresh panel. Remaining batch
requests stop, but a request already sent may still complete.
When changes take effect
Workspace saves report how many running branch servers acknowledged the
updated set. An acknowledgment does not change the environment of an
application process that is already running: restart that run to use the
new values. CI entries apply to subsequent runs.
A failed or uncertain response retains the open draft. Metadata and version
numbers can help reconcile a change, but cannot reveal or verify its value.
Use the secrets form for values; do not put secrets into chat, Git commits,
issue descriptions, or support messages. 
