Wrangler and Cloudflare Vite plugin support .env files in local development
Wrangler and the Cloudflare Vite plugin now support .env files for managing secrets and environment variables during local development, in addition to the existing .dev.vars files. You can use .env and .env.<environment-name> files to define variables for different environments.
Now, you can use .env files to provide secrets and override environment variables on the env object during local development with Wrangler and the Cloudflare Vite plugin.
Previously in local development, if you wanted to provide secrets or environment variables during local development, you had to use .dev.vars files.
This is still supported, but you can now also use .env files, which are more familiar to many developers.
Using .env files in local development
You can create a .env file in your project root to define environment variables that will be used when running wrangler dev or vite dev. The .env file should be formatted like a dotenv file, such as KEY="VALUE":
TITLE="My Worker"
API_TOKEN="dev-token"
When you run wrangler dev or vite dev, the environment variables defined in the .env file will be available in your Worker code via the env object:
export default {
async fetch(request, env) {
const title = env.TITLE; // "My Worker"
const apiToken = env.API_TOKEN; // "dev-token"
const response = await fetch(
`https://api.example.com/data?token=${apiToken}`,
);
return new Response(`Title: ${title} - ` + (await response.text()));
},
};
Multiple environments with .env files
If your Worker defines multiple environments, you can set different variables for each environment (ex: production or staging) by creating files named .env.<environment-name>.
When you use wrangler <command> --env <environment-name> or CLOUDFLARE_ENV=<environment-name> vite dev, the corresponding environment-specific file will also be loaded and merged with the .env file.
For example, if you want to set different environment variables for the staging environment, you can create a file named .env.staging:
API_TOKEN="staging-token"
When you run wrangler dev --env staging or CLOUDFLARE_ENV=staging vite dev, the environment variables from .env.staging will be merged onto those from .env.
export default {
async fetch(request, env) {
const title = env.TITLE; // "My Worker" (from `.env`)
const apiToken = env.API_TOKEN; // "staging-token" (from `.env.staging`, overriding the value from `.env`)
const response = await fetch(
`https://api.example.com/data?token=${apiToken}`,
);
return new Response(`Title: ${title} - ` + (await response.text()));
},
};
Find out more
For more information on how to use .env files with Wrangler and the Cloudflare Vite plugin, see the following documentation:
Source: original entry ↗
More from Cloudflare
Follow Cloudflare to get its new changes in your feed and email digest.
Cloudflare One Client for macOS 2026.8.2100.0
GA release for macOS Cloudflare One Client with improved split tunnel handling that no longer briefly blocks traffic during reconnects, support for non-RFC 1918 local IPv4 networks, faster connects with lower memory use, and numerous reliability fixes across DNS, reauthentication, and client stability.
Cloudflare One Client for Windows 2026.8.2100.0
This GA release improves split tunnel reliability, adds support for non-RFC 1918 local networks, optimizes connection performance with faster reconnections and lower memory usage, and includes numerous bug fixes for DNS, registration, and network handling. The client now features a service recovery mechanism that automatically restarts on system unlock and better handles large hosts files without blocking traffic.
Cloudflare One Client for Linux 2026.8.2100.0
New GA release for Linux with improved split tunnel handling that no longer briefly blocks traffic during reconnects, support for non-RFC 1918 local IPv4 networks, faster tunnel reconnections, and lower memory usage. Includes numerous stability and reliability fixes for DNS, reconnection behavior, and crash issues.