Documentation Environment variables

Environment variables

The environment variable manager stores your app's configuration per project and environment. Values are stored in CloudCode's database and protected by row-level security, so only you can read them. One-click deploys send them to Vercel.

1
Open the manager
Open a Project Dashboard tab and select Env Vars.
2
Pick an environment
Variables are scoped to Development, Staging or Production. Use "Copy shared vars to another environment" to duplicate a set.
3
Add a variable
Enter a KEY and a value, and tick Secret for sensitive values. Secrets are masked in the list (click the eye icon to reveal one) and are left out of the .env.example CloudCode generates.
4
Workspace overrides
Workspaces inherit the project's variables. Click an inherited value to create a workspace-specific override.
In one-click deploys
  • A deploy sends the variables of the environment you deploy to (the preview toolbar always uses Production). The deploy service reads them on the server after checking that you own the project. Values never pass through the browser and are never logged
  • Deploying a single workspace from the Dashboard applies that workspace's overrides on top of the project's variables
  • Each variable is available to the build (Vite exposes only VITE_-prefixed ones to the browser as import.meta.env.VITE_*) and, at runtime, to server code such as Node.js apps and Next.js server routes as process.env
  • Names Vercel reserves (for example AWS_REGION, TZ or anything starting with VERCEL_) and names that aren't valid identifiers are skipped, and the deploy log lists them
  • Pure static deploys have no build step, so nothing substitutes the variables into the files
  • The dev preview doesn't receive them
Other uses
  • When you push to GitHub and the repo has no .env.example, CloudCode generates one from your Production variables (secret values replaced by placeholders), along with a .gitignore that excludes .env files
  • The agent's environment check compares the variables your code references against the names defined here and reports any that are missing
Getting configuration into your app

In a Vite app, read browser-safe values such as an API base URL or a Supabase URL and anon key from import.meta.env.VITE_*. Keep real secrets server-side, for example as Supabase edge-function secrets, or as variables without the VITE_ prefix that only server code reads. If you deploy from GitHub through your own Vercel project, set variables in Vercel.

typescript
// src/lib/config.ts: VITE_ values are inlined at build time and shipped to every visitor
export const API_BASE_URL = import.meta.env.VITE_API_BASE_URL;

// Supabase edge function (server-side): secrets set with `supabase secrets set`
const secret = Deno.env.get("MY_SECRET_KEY");
Warning
Anything in your frontend code, including VITE_ variables in a Vite build, is publicly readable. Never put API secrets there.