Environment files

In 27.0.29, keep deployment values in optional env/*.env files and reference them with @env:KEY@. One project can use different hosts, ports, or labels without rewriting its pages and connectors.

Create and select an environment

1. Open the AVstudio project. Click env: create in the status bar, run Create env file, or use that command from the project's Explorer context menu.
2. Enter a name such as development. The editor appends .env when omitted, creates env/ if needed, and opens the file.
3. Replace the comment template with the values for this deployment and save it:

API_HOST=https://api.example.invalid
ROOM_NAME=Conference Room
PANEL_PORT=5442
USE_TLS=true

4. If you have multiple files, click the env status item or run Select active env file to choose one.
5. Open the consuming page or connector and replace the appropriate literal with a token, for example @env:API_HOST@ in a Web connector's Host field.
6. Save and run Run Project Health Check. Test the values in Live Preview.

The active editor environment is stored in VS Code workspace state. One file is selected automatically; with multiple files and no saved choice, the first sorted file is used. There is no “none” selection once files exist. Without files, the status item offers creation and a project using no env tokens remains valid.

Token scope

Location	Supported behavior
Page, container, and element render properties	Resolve against the active file; a whole token preserves the inferred value type.
Element and page action fields	Environment tokens resolve with the owning render context.
Variable- or parameter-owned action values	Environment tokens do not resolve here.
Connector connection fields	All seven connector types support env values, including Web headers. Values resolve when the driver starts; switching env in Live Preview restarts affected connectors.
avstudio.config	Project name, archive name/type, splash image, theme, logging, and start page may use env tokens.

Where offered, use the dynamic picker's Environment tab. Not every field exposes that tab; the token can also be typed directly into a supported field. Unknown keys stay literal and are reported by the health check.

File format

Use one KEY=value per line. Recommended keys use uppercase letters, digits, and underscores; token keys accept [A-Za-z0-9_]{1,64}. Blank lines and # comments are ignored. An inline comment starts at a # preceded by whitespace; a URL fragment such as https://host/#status is preserved.

Single or double quotes are stripped and their contents are used literally. There is no shell execution, escape processing, or ${VAR} interpolation. true and false become booleans, JSON-style numbers become numbers, and other values remain strings; leading-zero values such as 007 remain strings. The last duplicate key wins.

Keep the same set of keys across deployment files; the health check reports inconsistent keys. Each file should supply the values required by the shared project.

Choose the production environment

Build project selects its environment independently of the editor. With multiple env files, the build asks which one to use; cancelling aborts the build. One file is used automatically. With none, the build proceeds without env values.

Review the chosen environment before building and test the exported result. Selecting a development environment for preview does not select it for the next production build.

New projects ignore env/*.env in Git while retaining *.example.env templates. Existing projects need their ignore rules reviewed. Share placeholders in example files and provide actual deployment values separately. Resolved values are included in the delivered application where used; an ignored env file does not make a browser application a secret store. See Source control and Build and deployment.