Build Variables & Secrets

Store credentials, tokens, and other values your cloud build needs, without putting them in vibeview.json or your app’s source. Set them once from the CLI and every matching cloud build picks them up automatically.

This is the recommended way to give a cloud build an API key, a signing credential, or any other sensitive value. For non-secret configuration (a build flavor, a feature flag), the plain build.env map in vibeview.json still works — see Cloud Builds.

Visibility levels

Every variable has one of three visibility levels, set when you create it:

secret is the strictest level, and it’s the default wherever you create a variable without choosing one: vibeview env set stores secret unless you pass --plain or --sensitive, and the dashboard’s add-variable dialog preselects it. Once set, a secret value cannot be retrieved again by anyone, through the CLI, the API, or the dashboard. If you forget a secret’s value, there’s nothing to recover — set it again with a new value.

plain and sensitive values can both be read back later (for example with env pull, below). The difference is only what happens in build logs: sensitive values are masked wherever they appear in output, plain values are not. Use plain only for values you’re comfortable seeing appear in a build log verbatim.

Scopes

A variable is either organization-wide or tied to a specific app. Organization-wide variables apply to every app’s builds; an app-scoped variable applies only to that app. When an organization-wide variable and an app-scoped variable share the same name, the app-scoped one wins for that app’s builds.

File variables

Some credentials are files rather than short strings — a service-account JSON key, an Android keystore, a signing certificate. Upload one with env set --file, and it’s made available to your build the same way any other variable is: as an environment variable. The variable’s value is the path to the file inside the build environment, not the file’s contents. Reference it in your build command or scripts the same way you’d reference any file path passed in via the environment.

The file itself is kept outside your project’s source tree, so a normal build cannot accidentally pick it up and bundle it into your app’s artifact.

Managing variables from the CLI

vibeview env list [--app <id>] [--json]
vibeview env set NAME [VALUE] [--secret|--sensitive|--plain] [--file <path>] [--app <id>]
vibeview env rm NAME [--app <id>]
vibeview env pull [--app <id>] [--out .env]

By default env set stores the value as secret — the safest option. Pass --plain or --sensitive explicitly to choose a different visibility. Add --app <id> to scope a command to one app; omit it for the organization-wide scope.

Setting a variable

vibeview env set STRIPE_WEBHOOK_SECRET
# Value for STRIPE_WEBHOOK_SECRET: (hidden input)

Omitting VALUE prompts for it with hidden input when you’re running the command interactively. You can also pass the value directly, which is useful in scripts:

vibeview env set API_BASE_URL "https://api.example.com" --plain
vibeview env set ANDROID_KEYSTORE --file ./release.keystore --app app_abc123

Listing variables

vibeview env list --app app_abc123

env list never prints a value, at any visibility — it shows each variable’s name, visibility, scope, and (for plain/sensitive string values) a short hint. secret values and file variables show no hint.

Removing a variable

vibeview env rm STRIPE_WEBHOOK_SECRET

Pulling values for local development

vibeview env pull --out .env

env pull writes plain and sensitive values to a local file so you can mirror your cloud build’s configuration during local development. secret values and file variables are never included — pulling them isn’t possible by design. VibeView warns if the target file isn’t covered by your project’s .gitignore, and writes the file so only you can read it.

Limits

Names must be valid environment variable names: letters, digits, and underscores, and they can’t start with a digit.

Who can do what

Setting or removing a variable requires the Admin role in your organization. Listing variables requires any member role. Pulling values with env pull requires the Developer role or above.

Masking in build logs

sensitive and secret values are masked wherever they appear in your build’s log output. Masking has real limits, the same ones any build system with this feature has:

• Only single-line values are masked. A value that spans multiple lines isn’t matched.
• Values shorter than 8 characters are not masked. Short values match too much ordinary build output to mask reliably, so they’re left alone.
• A transformed value can’t be matched. If your build script splits a secret across lines, re-encodes it, base64s it, or otherwise changes its form before printing it, the masked pattern no longer matches and the transformed value will appear in the log unmasked.
• File variables are not masked. Masking applies to variable values, and a file variable’s value is the path to the file, not its contents. If your build prints the contents of a stored file — for example cat-ing a service-account JSON while debugging — those contents appear in the log unmasked. Treat a file variable’s contents as unmasked everywhere.

Masking protects against accidental disclosure — a value that ends up in a log because a tool prints its environment, or a command echoes an argument. It is not protection against your own build script deliberately printing or exporting one of its variables: a build necessarily has its secrets available in plain text while it runs, the same way any CI system’s build does. Only put a value in a build variable if you trust the build script that will run with it available.