Workspace Runtime, Preview, and Publishing
How runtime defaults, live preview startup, static preview files, and published artifact site settings map to the Config tab.
Where you see this in the app
These controls live in the post-level Workspace config & automations panel, especially the Config tab.
The settings are grouped around how the workspace starts, how preview content is found, and how a published artifact site is served.
Runtime defaults for interactive workspaces
The Runtime defaults group affects how interactive workspace launches behave when no one-off override is provided.
| Setting | What it means to an end user |
|---|---|
| Live preview startup mode | Whether the app should try to start a live app, require it, or skip it and use static preview only |
| Live app start command | The command used to start the live app when live preview is allowed |
| Live app working dir | The workspace subdirectory the live app should start from |
| Live app install command | An optional install step before the live app starts |
The three startup modes should be understood like this:
| Mode | End-user meaning |
|---|---|
AUTO | Try the live app first, then fall back to static preview if needed |
LIVE_ONLY | The live app is required; static preview is not the fallback |
STATIC_ONLY | Do not start a live app; use static preview only |
AUTO is the most forgiving mode when the workspace may support both styles.
Static preview settings
Static preview is the browser-visible file-based preview for the workspace before you are talking about the separately published artifact site.
| Setting | Plain-English meaning |
|---|---|
| Static preview directory | The folder the app should treat as the root of the preview files |
| Static preview entry file | The first file the preview should open, such as index.html |
| Static preview routing | Whether the preview behaves as plain static files or as an SPA with fallback routing |
Static preview entry file is important because it tells the app which file should open first inside the chosen preview directory. If the directory is right but the entry file is wrong, the preview can still feel broken.
Use Single-page app fallback when your preview needs front-end routing behavior instead of simple file-by-file navigation.
Published site settings
The published site controls look similar, but they apply to the artifact site you intend to share as the stable published output.
| Setting | Plain-English meaning |
|---|---|
| Published site directory | The folder that should be published as the artifact site |
| Published site entry file | The first file the published site should open |
| Published site routing | Whether the published site behaves like plain static files or an SPA |
These controls matter because the published site is the outward-facing deliverable, not just the working preview.
How to think about preview vs published site
A practical mental model is:
- runtime defaults decide how the workspace experience starts,
- static preview decides what viewers see inside the workspace preview flow,
- published site settings decide what the separately published artifact site exposes.
Those are related, but they are not the same surface.
If a workspace feels correct internally but the public artifact site feels wrong, the published-site settings are the first place to inspect. If the workspace preview itself feels wrong before publication, the static preview settings are the first place to inspect.
See it in action
Previous
Workspaces, Artifacts, and Automations
How the post workspace works, how it differs from artifacts, and what the main automation and access controls mean for end users.
Next
Workspace Automation Controls
The end-user guide to schedule setup, webhook triggers, Telegram and WhatsApp controls, and what each workspace automation setting changes.