Skip to content
Subaya

Security & privacy

How the suya CLI handles credentials, and how Subaya isolates your data.

API keys are secrets

Section titled “API keys are secrets”

SUBAYA_API_KEY is a credential that resolves directly to an identity on the platform. Treat it like any other secret:

  • Never commit it to a repository or bake it into an image.
  • Inject it through environment variables or your CI/CD secret store.
  • Issue and revoke keys from the console, and scope them to the workload that needs them.
Terminal window
export SUBAYA_API_KEY="sk_..."
suya auth whoami      # confirm the identity the key resolves to

Credential precedence

Section titled “Credential precedence”

When more than one credential is present, suya resolves in this order:

  1. The --token global flag
  2. SUBAYA_API_KEY
  3. The locally stored OAuth token

The --token flag takes precedence over everything, so an explicit token on the command line always wins — useful for one-off overrides, but avoid putting long-lived secrets in shell history.

Token storage

Section titled “Token storage”

The OAuth browser flow (suya auth login) stores its token locally under ~/.config/suya/. This directory holds your active session; protect it with normal filesystem permissions. To clear it and revoke the token on the server:

Terminal window
suya auth logout      # log out and revoke the local token
suya auth status      # confirm local auth state, no server call

Tenant isolation

Section titled “Tenant isolation”

Subaya’s tenancy is scoped org → workspace → project:

  • An organization is the top-level tenant — billing, members, and licenses live here.
  • A workspace groups projects within an org.
  • A project is the unit of work.

Data is isolated between organizations and between workspaces: credentials and queries are scoped to the tenant they belong to, so one org’s designs, simulations, and artifacts are not visible to another. See Core concepts for the full tenancy model.

Section titled “Related”