Workspace Defaults, Env Vars, and Runtime Commands
How the Defaults tab controls live preview startup, static preview and published-site paths, JSON env/secrets, and who can open or edit a workspace.
Where you see this in the app
This page documents the Defaults tab inside Workspace config & automations.
The key sections are:
| Section | What it controls |
|---|---|
Runtime defaults | How preview startup behaves and where files are served from |
Env vars (JSON) | Plain configuration values available to the workspace |
Advanced defaults -> Secrets (JSON) | Sensitive values that should not live in normal env text |
Save config | Persist the current per-post defaults |
Runtime defaults and startup mode
The Live preview startup mode sets the app’s overall preview strategy.
| Mode | End-user meaning |
|---|---|
AUTO (app first, static fallback) | Try a live app preview first, then fall back to static output |
LIVE_ONLY (app required) | Require a working live app startup path |
STATIC_ONLY (never start app) | Never try to boot a live app server |
The related fields support that mode:
Live app start command (optional)Live app install command (optional)Live app working dir
These are best thought of as the startup recipe for the interactive preview.
Preview and published-site paths
The defaults tab separates preview paths from published-site paths on purpose.
| Field | Meaning |
|---|---|
Static preview directory | Folder used for the in-app static preview |
Static preview entry file | First file opened for that preview |
Static preview routing | Whether preview behaves like plain static files or SPA fallback |
Published site directory | Folder used when publishing the artifact site |
Published site entry file | First file opened on the published site |
Published site routing | Static-files vs SPA fallback behavior on the published site |
Preview and published output often point at the same directory, but they do not have to be treated as the same concept.
Env vars, secrets, and advanced defaults
The JSON fields are per-post defaults, not just one-run overrides.
| Field | What it is for |
|---|---|
Env vars (JSON) | Normal named configuration values |
Secrets (JSON) | Sensitive defaults stored separately in the advanced area |
Default container tier | Preferred runtime tier for this post |
These values are startup context for future workspace sessions and runs. They are not automatically visible to end users in public UI, but they affect how the workspace behaves.
How to think about Save config
Save config stores the current defaults for that post.
The practical mental model is:
- use
Defaultsfor persistent post-level behavior, - use the
Runstab for one-off overrides, - save the stable baseline here once the workspace behaves the way you want.
That separation is important. Defaults define the reusable behavior. Manual runs test exceptions.
Related docs
See it in action
Previous
Workspace Start Errors, Capacity, and Credits
How workspace launch failures are presented to users, what busy-controller and concurrency states mean, and when AI-credit balance blocks a launch.
Next
Workspace Templates, Pools, and Replace Behavior
How the template gallery works, what details like publish target and entry file mean, and why applying a template can replace files or restart the workspace on a different pool.