Environment Variables & Secrets
Exovon provides enterprise-grade secret management for your applications. Sensitive variables like database URLs, API tokens, and private encryption keys are stored encrypted at rest in Google Cloud Secret Manager and injected securely into your serverless containers without ever touching build logs or public source code.
System-Reserved Environment Variables
Exovon automatically provisions and injects standard system variables into your container runtime environment:
| Variable Name | Example Value | Description |
|---|---|---|
| PORT | 8080 | The port your HTTP server must listen on to receive traffic from the Edge Router. |
| DATABASE_URL | postgres://user:pass@ep-...neon.tech/neondb | Automatically injected when you provision an ExoStore database cluster. |
| EXOVON_REGION | asia-south1 | The geographic cloud region where your container is currently executing (Mumbai, India). |
| EXOVON_DEPLOY_ID | dpl_9a2f1b4c8e... | Unique immutable SHA hash identifying the active deployment revision. |
| NODE_ENV | production | Defaults to production in live deployments to enable framework optimizations. |
Build-Time vs. Runtime Secrets Lifecycle
Understanding the distinction between build-time client bundling and container runtime secret injection prevents credential leaks and unnecessary full rebuilds:
Server Runtime Secrets (Instant Update)
Variables without a public prefix (e.g. STRIPE_SECRET_KEY, DATABASE_URL, JWT_SECRET) are stored in Google Cloud Secret Manager and decrypted directly into container memory (process.env) at launch.
2-Second Hot Restart
Updating runtime secrets spins up fresh container instances immediately with zero downtime. No container rebuild required.
Build-Time Public Variables (Bundled)
Variables prefixed with framework identifiers are inlined directly into client-side JS bundles during the compilation phase:
Next.js: NEXT_PUBLIC_SUPABASE_URL
Vite: VITE_API_BASE_URL
Astro: PUBLIC_ANALYTICS_ID
Requires Rebuild
Because these strings are baked into static assets, updating a public variable triggers a new build pipeline before serving.
Managing Variables via CLI & Dashboard
Option 1: Exovon CLI (npx exovon env)
Manage your project's secrets directly from your local terminal or GitHub Actions CI/CD pipelines:
# 1. Add or update a production secret (encrypted immediately)
npx exovon env add STRIPE_SECRET_KEY "sk_live_..." --project my-app
# 2. List all configured keys (values remain securely masked)
npx exovon env ls --project my-app
# 3. Pull production variables into your local development environment
npx exovon env pull .env.local --project my-app
# 4. Remove a deprecated secret
npx exovon env rm OLD_TOKEN --project my-appOption 2: Exovon Console UI
- Open your Project Dashboard on
exovon.in/dashboard. - Click the Variables tab in the project navigation.
- Add Key-Value pairs and select environment scope (Production, Preview, or Development).
- Click Save & Encrypt. Secrets are immediately synced to Secret Manager.
Application secrets are securely bound to Cloud Run containers as native environment variables (process.env) at container launch. When you update an environment variable or secret, Exovon deploys a zero-downtime rolling revision update, seamlessly spinning up new container instances with the updated values and draining existing connections. For static sites (Vite/React), updating build-time variables prompts an instant rebuild and edge cache purge.
Frequently Asked Questions
Are environment variables visible in build logs?
No. Exovon automatically redacts all configured variable values from stdout and stderr logs during both container build and runtime execution to prevent credential leakage.
Is there a limit on how many environment variables I can store?
Environment variable limits are structured by plan: Free (Hobby) includes up to 6 variables per project, Starter includes 15 variables, Pro includes 25 variables, and Heavy includes unlimited variables with dedicated customer-managed encryption keys (CMEK).