Environment and secrets

getEnv() is the request’s c.env. On Cloudflare that is the Worker bindings object. On Node during vite dev, the Hono adapter exposes .env files on process.env, and the request context still has an env object.

import { getEnv } from "better-router";

export function loader() {
  const env = getEnv();
  return { appUrl: env.APP_URL };
}

Prefer getEnv() in loaders, actions, and middleware so the same code runs on Workers. Do not sprinkle process.env through those files.

Files

File	Used by	Commit?
`.env` / `.env.local`	Vite, Node `vite dev`	no
`.dev.vars`	`wrangler dev`	no
`wrangler.jsonc` `vars`	Cloudflare Workers (public)	yes
`wrangler secret put`	Cloudflare Workers (private)	no

Do not put secrets in vite.config.ts or client pages. Anything referenced as import.meta.env.VITE_* is bundled for the browser.

Node vs Workers

On Workers, process.env is not your Wrangler bindings. Bindings only exist on c.env / the env argument of fetch / scheduled / queue / email.

src/worker.ts

import { defineWorker } from "better-router/worker";

export default defineWorker({
  async scheduled(_event, env) {
    const url = env.APP_URL;
    console.log("cron", url);
  },
});

Inside HTTP handlers, getEnv() is that same env. In scheduled / queue / email, pass env yourself — getEnv() is request-scoped and will throw.

Client env

The browser only sees import.meta.env.VITE_*. Use that for public values such as VITE_APP_URL. Never prefix secrets with VITE_.

`.env` example

.env

APP_URL=http://localhost:5173

Get started

Routing

Rendering

Deploy

Guides

Reference

Files

Node vs Workers

Client env

`.env` example

​Files

​Node vs Workers

​Client env

​.env example

Files

Node vs Workers

Client env

`.env` example