Guides, setup, comparison, and practical continuation for owned repos.

Docs · Environment variables

Environment variables and your own API keys

Most real apps need a few secrets to run — a database URL, a Stripe key, an OpenAI token. Virex generates the wiring; you provide the keys. This page explains what Virex asks for, what we never see, and how the flow works on each plan.

The short version: encrypted, never plaintext, never shared

The most important thing first.

Virex stores API keys encrypted with AES-256 GCM, using a master key that only lives on our server (BYOK_MASTER_KEY). The plaintext value never lands in our database, our application logs, our telemetry, or the downloaded build zip.
The encrypted blob lives at projects/<your-project-id>/env.json. Sub-processors (Supabase Storage) only see opaque ciphertext — they cannot read your keys.
Live preview and edits decrypt the values inside the sandbox at runtime, so the preview can talk to Stripe / Supabase / your AI provider with your real keys.
The downloaded zip intentionally does NOT include .env.local — a downloaded zip can end up in a public GitHub repo, and we don't want secrets to leak that way. The zip ships with .env.example listing what's needed; you fill in real values locally.
You can rotate, edit, or delete a key any time via the BYOK panel — your changes overwrite the encrypted blob.

What this means in practice

If you build a repo with your Stripe key, then come back tomorrow and ask Virex to add a feature, the live preview keeps working because we decrypt your stored Stripe key at sandbox boot. Sub-processors and humans (including us) cannot read it — only the running sandbox can. The downloaded zip stays clean.

What env vars Virex asks for

Depends on what your app does. The engine detects required env vars from the features your prompt asks for.

Database (most apps with state)

If your app needs to store anything, Virex generates a Supabase schema and asks for NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY (and SUPABASE_SERVICE_ROLE_KEY when server-side writes are needed).

Payments (ecommerce / paid SaaS)

If your app accepts payment, you'll see STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET (plus NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY for the client side).

AI features (chatbot, summariser, classifier)

If your app uses LLM features at runtime — a chat box that talks to GPT, an article summariser — Virex asks for the relevant API key (ANTHROPIC_API_KEY, OPENAI_API_KEY, etc) and wires it server-side so the key never reaches the browser.

Email

If your app sends transactional email (welcome, password reset, receipts), Virex asks for the Postmark/Resend/SendGrid key + the from-address.

Auth (Google / GitHub / etc.)

If your app has OAuth login, Virex asks for the OAuth client id + secret per provider you choose. These are set on the Supabase project, not in your env file directly.

You don't need every key on day one

Virex always ships an .env.example with the full list and an .env.local with placeholder values. The build runs locally without any real keys — you'll see placeholders in the preview. Add keys when you're ready to connect each piece for real.

How each plan handles env vars

Same privacy guarantee on every plan — the difference is how the engine asks for them.

Starter — paste during build, encrypted for preview + edits

At build time the chat asks 'Do you have your own keys for X, Y, Z?' with a 60-second timer. Click yes, paste them, the values are encrypted at rest and used by the live preview + subsequent edits so your work flows naturally. Click no (or let the timer expire) and the build ships with placeholders that you fill in after downloading. Skipping never blocks the build.

Premium — same as Starter, plus auto-detect from existing projects

If you've used Virex before with the same vendors, Premium pre-fills the env var NAME you used previously (the value stays empty — we don't fill values across projects). Saves you remembering whether you called it STRIPE_KEY or STRIPE_SECRET_KEY. You paste a value or skip.

Pro — same, plus GitHub Secrets push at deploy

When Pro users hit 'Deploy to Vercel via GitHub', the keys you saved are decrypted server-side once and pushed directly into the GitHub repo's Secrets (encrypted by GitHub from then on). The deploy step picks them up automatically. We don't keep a copy beyond what's already encrypted in your project's env store.

Where keys end up — three places, all encrypted

(1) projects/<id>/env.json in our Supabase Storage, encrypted with BYOK_MASTER_KEY — used by the sandbox at preview boot. (2) GitHub Secrets of any repo you push to via the one-click ship — encrypted by GitHub. (3) Your local .env.local that YOU create from .env.example after download. Plaintext only lives where you put it — never in our infrastructure.

Where to add keys later, after the build

If you skipped the env-var step or want to add a key after downloading, here are the standard paths.

Local development

Open `.env.local` in your editor and replace the placeholder with your real value. Restart `npm run dev`. The new key picks up on the next render.

GitHub Secrets

Repo → Settings → Secrets and variables → Actions → New repository secret. Name and value. Used by GitHub Actions deploys + by the integration we set up if you used the GitHub one-click ship.

Vercel

Project → Settings → Environment Variables → Add. Pick which environments (Production / Preview / Development) — usually all three for app-critical keys, Production only for live-only ones like Stripe. Redeploy after adding.

Common questions

Short answers to what people usually ask.

Can I see what keys Virex asked for after the build?

Yes — the .env.example file in your downloaded repo lists every required env var with a short description. .env.local has the actual structure with placeholders so you can compare.

What if I'm not sure which keys I need yet?

Skip them. Builds run with placeholders. The features that need real keys will display a friendly 'connect your Stripe account' state instead of failing. You fill the keys in when you're ready.

Does Virex log my prompts in a way that could leak my keys?

No. The build prompt (your project description) is logged for engine telemetry and abuse review. Keys are entered in a SEPARATE flow that never touches the prompt log. Even if someone could see your prompt, they wouldn't see your keys — they're in a different code path entirely.

What if a key is exposed by accident — say, I push it to a public GitHub repo?

That's on you to remediate (rotate the key with the vendor and force-push the cleaned commit), but we have your back on the path that leads there: pasted keys go into .env.local (which our generated .gitignore excludes from commits) or directly into GitHub Secrets (which are encrypted and not visible to anyone who clones the repo). The only way a key leaks is if you actively add .env.local to git and push it. We can't undo that, but the default setup prevents it.