Environment Variables on Varity

Varity TeamCore Contributors

Supply the configuration and third-party secrets that your application owns, such as an OpenAI, Stripe, SendGrid, or Resend key. Varity does not create those accounts or provide shared development credentials.

If Varity provisions a supported attached service for a deployment, the runtime injects that service’s reserved connection variables. See Auto-wired Services for that separate contract.

Add Custom Variables

Create .env.varity in the project root and add it to .gitignore:

.env.varity

OPENAI_API_KEY=sk-...
STRIPE_SECRET_KEY=sk_live_...
MY_CUSTOM_VAR=some-value

Then deploy:

varitykit app deploy

The CLI uses the first file it finds in this precedence order:

1. .env.varity
2. .env.local
3. .env

It validates names, filters reserved platform keys, and sends the remaining values as write-only deployment input. Your application reads them through its normal process environment.

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

Note

Only one environment file is loaded. Values from lower-precedence files are not merged into the selected file.

Reserved Runtime Variables

Do not try to override runtime-owned fields such as NODE_ENV, PORT, NODE_OPTIONS, or APP_NAME. Connection variables for an attached service, including DATABASE_URL, REDIS_URL, MONGODB_URI, and MYSQL_URL, are also reserved when that service is provisioned. The platform contract owns the exact reserved set.

Migration-specific keys from other hosting platforms are filtered from dynamic deployments so unrelated provider configuration is not forwarded accidentally.

There is no automatic NEXT_PUBLIC_VARITY_APP_ID, shared local credential, or application VARITY_API_KEY. If your application itself calls a Varity API, create and scope that credential explicitly, store it as a server-side secret, and never expose it through a browser-public prefix.

Public Versus Server-only Values

Framework prefixes such as NEXT_PUBLIC_, VITE_, and REACT_APP_ usually embed values into browser code. They are suitable only for deliberately public configuration. Never put a secret in a public-prefixed variable.

Security Checklist

• Keep every environment file containing secrets out of version control.
• Use separate credentials for development and production.
• Rotate a credential after suspected exposure.
• Treat environment values as write-only; logs and read APIs should not echo them.
• The compute host that runs your deployment can read its environment values. Do not put data in an environment variable that the host must not see.
• Test the application locally with your own development credentials before deploying.

Troubleshooting

If a variable is absent after deploy:

1. Confirm the file name and precedence order above.
2. Confirm the variable name is a valid shell identifier and is not reserved.
3. Redeploy, then follow the returned operation to a terminal state.
4. Check runtime logs for the variable name only; never print its value.

Use varitykit doctor for local tool and connectivity checks. It does not prove that an application secret was created for you or that a deployed service is healthy.