Environment Variables

Varity Team Core Contributors Updated May 2026

Varity manages most credentials automatically. You only need to set environment variables for services you manage yourself, like your own API keys for OpenAI, Stripe, SendGrid, and similar third-party services.

Custom Environment Variables

If your app uses third-party APIs (OpenAI, Stripe, SendGrid, Resend, or any other service), you need to inject those API keys into your deployment. Varity reads them from a .env file during varitykit app deploy and passes them through to your running app.

Step 1: Create a `.env.varity` file

Create .env.varity in your project root with your custom keys:

# Third-party API keys
OPENAI_API_KEY=sk-...
STRIPE_SECRET_KEY=sk_live_...
RESEND_API_KEY=re_...
SENDGRID_API_KEY=SG....
MY_CUSTOM_VAR=some-value

Step 2: Deploy

varitykit app deploy

The CLI reads your .env.varity file, filters out any reserved or platform-specific keys, and injects the rest directly into your deployment’s runtime environment. Your app code accesses them the same way as any environment variable:

const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

File precedence

When multiple .env files are present, Varity reads the first match (highest precedence wins):

File	When to use
`.env.varity`	Varity production secrets (overrides all others)
`.env.local`	Local overrides / Next.js convention
`.env`	Fallback for all environments

What gets passed through

Any key that is a valid shell variable name and is not reserved by Varity passes through automatically, including NEXT_PUBLIC_* variables.

Keys that are not forwarded (Varity sets these automatically):

Key	Set by
`NODE_ENV`, `PORT`, `NODE_OPTIONS`	Runtime defaults
`DATABASE_URL`, `REDIS_URL`, `MONGODB_URI`, `OLLAMA_URL`	Varity service wiring
`POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_DB`	Managed database config
`APP_NAME`	Deployment metadata

Platform migration keys (VERCEL_*, AWS_*, RAILWAY_*, RENDER_*, NETLIFY_*, FLY_*) are also filtered so they don’t leak into dynamic deployments.

Varity App Configuration

# Your Varity App ID (from developer portal)
NEXT_PUBLIC_VARITY_APP_ID=your-app-id

Optional Variables

These variables are only needed for specific use cases:

Variable	Required For	Default
`NEXT_PUBLIC_VARITY_APP_ID`	App identity	Dev default
`VARITY_API_URL`	Custom API endpoint	`https://varity.app`
`VARITY_API_KEY`	API authentication	Auto-provided

# Varity app ID (optional, dev defaults work automatically)
NEXT_PUBLIC_VARITY_APP_ID=your-app-id

In development, your app uses shared credentials automatically. No other variables are needed.

# Varity app ID
NEXT_PUBLIC_VARITY_APP_ID=your-app-id
VARITY_API_URL=https://varity.app
VARITY_API_KEY=your_production_api_key

Production credentials for storage and services are auto-provided by the CLI during deployment.

Framework-Specific Prefixes

Different frameworks require different prefixes for client-side variables:

Framework	Prefix	Example
Next.js	`NEXT_PUBLIC_`	`NEXT_PUBLIC_VARITY_APP_ID`
Vite	`VITE_`	`VITE_VARITY_APP_ID`
Create React App	`REACT_APP_`	`REACT_APP_VARITY_APP_ID`

Security Best Practices

Do:

Use .env.local for local development (git-ignored)
Store production secrets in your CI/CD platform
Rotate keys regularly

Don’t:

Commit .env files with real credentials
Use production keys in development
Share API keys in public repositories
Hardcode secrets in source code

Verifying Configuration

Run the doctor command to verify your configuration:

varitykit doctor

This checks:

Credential availability (auto-provided or manually set)
Network connectivity
API key validity
Project structure

Troubleshooting

Variables not loading

Check file name is exactly .env or .env.local
Restart your development server after changes
Verify no syntax errors in the file
Check framework-specific prefixes (NEXT_PUBLIC_, VITE_, etc.)

Credentials not working

Run varitykit doctor to diagnose. Credentials are auto-provided. If they fail, check your network connection.