Environment Variables

An app's environment variables live at its provider, Vercel or Google Cloud Run. telbase env and the dashboard's Env page read and write them there. Each app has its own.

Setting Variables

Set one or more variables from the command line:

bash

# Set a single variable
telbase env set --project my-app API_URL=https://api.example.com

# Set multiple variables at once
telbase env set --project my-app API_URL=https://api.example.com STRIPE_KEY=sk_live_...

# List all variables
telbase env list --project my-app

How your agent sets them

Following the skills, the agent sets values on the provider from a command, never through a file, and never echoes a secret back:

bash

# Vercel
printf '%s' 'value' | telbase vercel env add NAME production
openssl rand -hex 32 | telbase vercel env add SECRET_KEY production

# Cloud Run: on the deploy, always --update-env-vars (never --set-env-vars)
telbase gcloud run deploy <service> ... --update-env-vars SECRET_KEY="$(openssl rand -hex 32)"

A Cloud Run app has nowhere to keep variables before its first deploy, so they are passed on that deploy. Values baked in at build time (NEXT_PUBLIC_*, VITE_*, PUBLIC_*) must exist before the build.

Who can read values

telbase env list masks values unless you pass --show. Owners, admins and developers can read values; viewers see the names only.

Bulk Import & Diff

Push and pull environment variables in bulk using .env files.

bash

# Push variables from a local file
telbase env push --project my-app --file .env.production

# Pull remote variables to a local file
telbase env pull --project my-app

# Compare local .env with remote variables
telbase env diff --project my-app

File format

The push command accepts standard .env format: one KEY=VALUE pair per line. Lines starting with # are ignored. Quotes around values are stripped.

Key Format Rules

Naming requirements

Variable keys must start with a letter or underscore, and contain only letters, numbers, and underscores. Keys are case-sensitive.

Valid examples:

DATABASE_URL
NEXT_PUBLIC_API_URL
_INTERNAL_SECRET
myVar123

Invalid examples:

123_KEY — cannot start with a number
MY-VAR — hyphens are not allowed
MY.VAR — dots are not allowed

When a change applies

Vercel — telbase env set and unset rebuild the live deployment so the app reads the new value. That counts as a deploy. A value added with telbase vercel env add applies to the next build.
Cloud Run — a change makes a new revision, which does not count as a deploy.

The POST /projects/:id/env/generate endpoint creates the common secrets an app lacks, such as JWT_SECRET and SESSION_SECRET, with cryptographically random values. See the Environment Variables API for details.

Database and Storage Values

An app's database and storage values come from commands, which the agent pipes to the provider under the names the app reads:

Value	Command
PostgreSQL, the running app (pooled)	`telbase db url <app> --pooled`
SQLite URL and the app's token	`telbase db url <app>`, `telbase db url <app> --token`
Migrations and seeds (direct URL, for one command)	`telbase db run <app> -- <command>`
Storage: `R2_ENDPOINT`, `R2_ACCESS_KEY_ID`, `R2_SECRET_ACCESS_KEY`, `R2_BUCKET_NAME`	`telbase storage credentials <app> --get <NAME>`

GCP reserved variables

On GCP Cloud Run, PORT, K_SERVICE, K_REVISION, and K_CONFIGURATION are reserved by the platform and cannot be overridden.

Next Steps

Full-Stack & Monorepos — variables across a frontend and a backend
CLI Reference — full env command reference with all flags
Environment Variables API — manage variables programmatically