Environments & Variables

A shared environment is an encrypted, repository-backed set of variables such as development, staging, or production. The environment name and type are visible project metadata; values remain encrypted at rest under .ghostable/.

Selecting an environment loads only values this device is authorized to read. The table shows version and update information so a reviewer can distinguish a recent change from an unchanged value without exposing history in plaintext.

Variables stay scoped to the selected shared environment; required missing keys remain visible above the table.

1. Select the plus control beside Shared environments.
2. Enter a stable lowercase name, such as staging.
3. Choose an environment type. Types influence policy and review behavior; they are not cosmetic labels.
4. Confirm the change, inspect the new environment, and commit the resulting .ghostable/ files.

Environment access is scoped. Creating an environment does not automatically grant every device permission to read or change it. Review Access & Automation before sharing production access.

Select the plus control in the variable toolbar to add a key. Use conventional uppercase names and provide a reason when Desktop requests one; the reason becomes part of signed, reviewable activity.

• Enabled variables are emitted normally when writing or injecting an environment.
• Commented variables can be represented as commented entries in supported file workflows.
• Secret values are masked in the table. Revealing a value only affects the current authorized device and interface session.
• Order can be managed so generated files remain predictable and easy to diff.

Select a variable row to open the detail panel. The panel separates the value from descriptive and policy metadata so teams can document a key without placing its secret in a note.

• Edit the value and record why it changed.
• Add an encrypted note for context that should travel with the value.
• Inspect version and update metadata.
• Configure dynamic-variable behavior when supported by the project.
• Add annotations used by tooling or team conventions.
• Review the validation rules that apply to the selected key.

Notes should explain ownership, rotation, or usage. Do not duplicate the secret value inside a note, annotation, commit message, or issue tracker.

Select a variable to inspect and edit its value, note, state, metadata, and policy details.

The banner above the table lists required keys missing from the selected environment. It is derived from project and environment validation rules. Add the missing value or intentionally adjust the rule; do not silence the signal by adding a meaningless placeholder to a production environment.