Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions src/content/docs/reference/environment-variables.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ title: Environment variables
description: Using environment variables to store secrets that vals can securely access
sidebar:
order: 1
lastUpdated: 2026-06-11
lastUpdated: 2026-08-17
---

import Val from "@components/Val.astro";
Expand All @@ -13,9 +13,9 @@ You can store secrets, keys, and API tokens as **Environment Variables** via the
Environment variables can be accessed via `Deno.env` or `process.env` within any file in your val.

- The "key" and "value" of each environment variable can be any string
- Vals can't set environment variables programmatically: Environment variables are only set via the settings page. Trying to update an environment variable, for example by using `Deno.env.set`, is a no-op.
- Vals can't set environment variables programmatically from inside val code. Environment variables are set via the settings page, API, or SDK. Trying to update an environment variable, for example by using `Deno.env.set`, is a no-op.

Newly set or updated environment variables don't reach isolates that are already warm, so your val can keep seeing stale values until it redeploys. Any edit to the val, however trivial, forces a redeploy and picks up the new values.
Environment variables set via the API or SDK (for example, `client.vals.environmentVariables.update` or the `add_env_var` tool) are picked up by a val on the next HTTP request against the same warm isolate — no redeploy needed. Environment variables set through the Val Town UI or settings page may behave differently and can require a val edit or redeploy before a warm isolate sees the new value.

### Deno.env

Expand Down