Environment variables

Give your hosted app its API keys and settings. Inverse stores them encrypted, sets them on the app's hosting for production and preview, and serves them to the running app.

From the terminal

Run these in the app's folder, or pass --app <id>.

npx inverse-embed env push .env         # replace all, after a key-only preview
npx inverse-embed env set API_KEY=sk_123 MODE=live
npx inverse-embed env rm MODE
npx inverse-embed env                   # list, values masked
npx inverse-embed env pull > .env.local
npx inverse-embed deploy --env .env     # push, then build

push asks before replacing unless you pass --yes. A plain deploy never uploads your .env: deploys skip .env* files, and only --env sends one.

In /dev

Open an app in /dev and find Environment. Upload a .env: your browser parses it and shows which keys it adds, updates and removes before anything is sent. You can also reveal, edit, add and remove single variables, then Save & sync.

When changes apply

Each save syncs to the app's hosting project, and each deploy syncs again first. The running app picks variables up on its next deploy, so redeploy after a change. If hosting isn't configured on the Inverse server, variables are saved but not synced, and loadEnv() is how the app reads them.

Reading them at runtime

Inverse also sets INVERSE_ENV_URL and INVERSE_ENV_TOKEN on the app. loadEnv() fetches the current values with that token and copies them into process.env, without overwriting anything already set. Outside Inverse it does nothing.

import { loadEnv } from "inverse-embed/env";

await loadEnv();
const stripe = new Stripe(process.env.STRIPE_KEY);

npx inverse-embed env rotate issues a new token and invalidates the old one. Redeploy so the app gets it.

Rules