Environment Variables

Telbase manages environment variables and secrets for your deployed apps. Variables are encrypted at rest, synced to your compute provider on every deploy, and scoped per service in multi-service projects.

Setting Variables

Set one or more variables from the command line:

bash

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

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

# Mark a variable as secret (masked in output)
telbase env set --secret STRIPE_SECRET=sk_live_...

# List all variables
telbase env list

Secrets & Encryption

All environment variables are encrypted at rest using AES-256-GCM. Variables flagged as secrets get additional protection:

Values are masked in telbase env list output
Values are masked in the dashboard
Values are never included in deploy logs

Telbase auto-detects common secret patterns and suggests marking them as secrets when you set them. Patterns include keys containing API_KEY, SECRET, PASSWORD, TOKEN, PRIVATE, and CREDENTIAL.

Always use --secret for credentials

While all variables are encrypted, the --secret flag ensures the value is never displayed in CLI output, logs, or the dashboard.

Multi-Service Scoping

In multi-service projects (monorepos), variables can be scoped to the entire project or to a specific service.

bash

# Project-level variable (shared by all services)
telbase env set SHARED_API_KEY=abc123

# Service-specific variable
telbase env set --service frontend NEXT_PUBLIC_API_URL=https://api.example.com
telbase env set --service backend DATABASE_URL=postgres://...

# List variables for a specific service
telbase env list --service backend

When a service deploys, it receives both project-level variables and its own service-specific variables. If the same key exists at both levels, the service-specific value takes priority.

See Full-Stack & Monorepos for more on multi-service project structure.

Bulk Import & Diff

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

bash

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

# Pull remote variables to a local file
telbase env pull

# Compare local .env with remote variables
telbase env diff

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

Provider Sync

When you set or update a variable, Telbase syncs it to your compute provider (Vercel or GCP Cloud Run) immediately. The variable is available to your app on the next deploy.

Redeploy after changing variables

Some providers require a redeploy for environment variable changes to take effect. Run telbase deploy after updating variables to ensure your app picks up the new values.

You can also generate common variables automatically via the API. The POST /projects/:id/env/generate endpoint creates standard secrets like JWT_SECRET and SESSION_SECRET with cryptographically random values. See the Environment Variables API for details.

Auto-Injected Variables

Telbase automatically sets the following variables when it provisions infrastructure. They are managed by the platform and overwritten on each deploy.

Do not set these manually

These variables are injected automatically. Setting them yourself may cause connection failures or unexpected behavior.

Feature	Variable	Notes
Database (Neon)	`DATABASE_URL`	Pooled connection via pgBouncer
Database (Neon)	`DATABASE_URL_UNPOOLED`	Direct connection (required for migrations)
Database (Turso)	`DATABASE_URL`	libsql:// URL
Database (Turso)	`DATABASE_AUTH_TOKEN`	JWT auth token
Database (Turso)	`TURSO_DATABASE_URL`	Alias of DATABASE_URL
Database (Turso)	`TURSO_AUTH_TOKEN`	Alias of DATABASE_AUTH_TOKEN
Storage (R2)	`R2_ENDPOINT`	S3-compatible endpoint URL
Storage (R2)	`R2_ACCESS_KEY_ID`	Access key
Storage (R2)	`R2_SECRET_ACCESS_KEY`	Secret key
Storage (R2)	`R2_BUCKET_NAME`	Bucket name
Runtime	`PORT`	Listening port (set by compute provider)

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 — multi-service variable scoping in practice
CLI Reference — full env command reference with all flags
Environment Variables API — manage variables programmatically