Security Model

RunEnv protects configuration values through encryption, authorization, and narrowly scoped delivery. The Dashboard, CLI, SDKs, Desktop app, and integrations communicate through the RunEnv API; clients do not connect directly to the database.

Encryption and delivery

  • At rest: values are encrypted with envelope encryption. Data-encryption keys are protected by a key-encryption key managed through the configured key-management boundary.
  • In transit: clients communicate with the RunEnv API over TLS.
  • At runtime: runenv run injects values into the child process environment instead of writing a .env file.

Access control

RunEnv authorizes requests at the organization, project, environment, namespace, and action boundary. Organizations commonly assign Owner, Admin, Editor, or Viewer roles, then apply project membership and narrower permissions where required.

RoleTypical capability
OwnerOrganization ownership, governance, and administrative control
AdminOrganization and project administration within delegated scope
EditorCreate and update permitted project configuration
ViewerRead permitted metadata; secret-value access depends on the explicit permission grant

The effective permission is the result of the requester's authenticated identity, organization role, project membership, namespace policy, and the requested action. A role label alone is not proof that a caller can reveal a secret value.

Safe operating practices

  1. Use service tokens only for automation, scope them to the smallest project and environment boundary, and rotate them regularly.
  2. Do not put tokens, secret values, authorization codes, or private keys in source code, issues, prompts, logs, artifacts, or documentation examples.
  3. Use Change Requests and audit history for sensitive changes.
  4. Use Hierarchical Namespaces for inherited governance boundaries.
  5. If a credential is suspected to be exposed, revoke or rotate it before investigating the surrounding logs.