Skip to main content
The ENV tab (in the sidebar when Code view is active) lets you manage environment variables for your project. Botflow stores them with the project and writes them into the sandbox as a .env file, so your dev server and production build can read them at runtime.

​
Viewing variables

Switch to Code view, then click the ENV tab in the left sidebar. The panel shows two sections:

​
System variables (read-only)

These are set automatically by the platform and cannot be changed. A common example is VITE_CONVEX_URL, which is injected whenever your project has a Convex backend configured. Your app can read these like any other env variable.

​
User variables

Variables you add yourself. These are persisted with the project and restored every time you open the workspace.

​
Adding a variable

In the ADD VARIABLE section at the bottom of the ENV panel:
  1. Enter the key (automatically uppercased, e.g. STRIPE_SECRET_KEY).
  2. Enter the value.
  3. Optionally check Mark as secret — secret values are masked in the UI after saving and never shown in plaintext again.
  4. Click + Add.
The variable is written to the project’s .env and picked up on the next dev server start or build. Already-running processes need to be restarted to see the change.
The .env file is regenerated from this panel each time you save, start the dev server, or deploy — so manage your variables here rather than editing .env by hand, since hand edits will be overwritten.
Prefix variables with VITE_ (for Vite-based web projects) to make them accessible in browser-side code. Without the prefix, the variable is only available in Node.js/server contexts.

​
Bulk import

Click the upload icon at the top of the ENV panel to paste in a .env file’s contents all at once. The format is standard dotenv: 
DATABASE_URL=postgres://user:password@host/db
STRIPE_SECRET_KEY=sk_live_...
NEXT_PUBLIC_API_URL=https://api.example.com
All variables are parsed and added. Duplicates overwrite existing values.

​
Exporting variables

Click the download icon to export all user variables as a .env file. Secrets are excluded from the export for security.

​
How variables are used

  • Dev server — variables are written to the sandbox’s .env file before the dev server starts. Your Vite or Next.js app can read them via import.meta.env.VITE_* or process.env.*.
  • Deploy — when you publish to Cloudflare Pages, user variables are bundled into the build environment. Secrets are passed as encrypted Cloudflare environment variables.
  • AI agent — the agent does not read variable values, only their keys. This means the agent can reference VITE_CONVEX_URL in generated code without ever seeing the actual URL.

​
Environment variables reference

​
System-injected variables

These variables are set automatically by the platform based on your project configuration:
VariableDescriptionInjected when
VITE_CONVEX_URLConvex backend URL for web projectsProject has Convex configured
VITE_UPLOADTHING_TOKENUploadThing file upload tokenProject uses UploadThing

​
Framework-specific prefixes

Different frameworks expose environment variables to client-side code differently: Vite projects:
  • Prefix with VITE_ to expose to browser code
  • Example: VITE_API_URL → accessible via import.meta.env.VITE_API_URL
  • Without prefix: only available in Node.js/server code via process.env
Next.js projects:
  • Prefix with NEXT_PUBLIC_ to expose to browser code
  • Example: NEXT_PUBLIC_API_URL → accessible via process.env.NEXT_PUBLIC_API_URL
  • Without prefix: only available on the server via process.env

​
Usage examples

Vite + React: 
// Access in component
const apiUrl = import.meta.env.VITE_API_URL;

// Conditional rendering based on env
const isDevelopment = import.meta.env.DEV;
Next.js: 
// Server-side (getServerSideProps, API routes)
export async function getServerSideProps() {
  const apiKey = process.env.STRIPE_SECRET_KEY;
  return { props: {} };
}

// Client-side
const apiUrl = process.env.NEXT_PUBLIC_API_URL;

​
Security

  • Secrets are stored encrypted in Botflow’s database and are never included in exports or logs.
  • Non-secret variables are stored in plaintext and visible to anyone with access to the project.
  • Never put production secrets (payment keys, database passwords) in non-secret variables.
  • Best practice: Use different keys for development and production. Rotate keys if you suspect exposure.