--- sourceDocument: Brazil Build or modify applications sourceDocumentLink: https://www.servicenow.com/docs/r/application-development Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil Build or modify applications ft:clusterId : - cadev bundleId : - cadev workflow : - Development, Data, and Analytics --- # Ways to preview a Lux experience # Ways to preview a Lux experience {#ariaid-title1} Release version: Brazil Updated September 29, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read Four mechanisms show you an app before it ships, from the Lux Lab Preview panel to a local production build. No shareable preview link is available, and no server-side staging view exists separate from your local dev server or a deployed instance. The four are the Lux Lab Preview panel, a local dev server with hot reload, a local production build, and server-rendered output on a deployed instance. ## Preview in Lux Lab {#ways-to-preview-an-experience__ways-to-preview-an-experience-preview-in-lux-lab} Lux Lab has a dedicated Preview panel: a live, embedded browser view of your running app, opened as an editor tab. The same local dev server described later in this topic backs the panel, proxied to the ServiceNow instance you are logged in to. The methods for opening the panel are described in the following table. {#ways-to-preview-an-experience__table-ways-to-preview-an-experience-open-methods__entry__2} | Method | What happens | |-|-| | Preview in the title bar | Starts the dev server if it isn't running, then opens the preview tab | | Run in the title bar | Starts the dev server; the preview tab opens when the server is ready | | Auto-open | The preview opens by itself when the dev server finishes starting | [Table 1. Preview panel open methods] {#ways-to-preview-an-experience__table-ways-to-preview-an-experience-open-methods} The Run button doubles as the stop control. It displays Run when the server is stopped, shows a transition indicator while it starts, and is set to Stop after the server is running. The preview panel carries a floating toolbar. Its controls are described in the following table. {#ways-to-preview-an-experience__table-ways-to-preview-an-experience-toolbar-controls__entry__2} | Control | What it does | |-|-| | URL bar | Shows the current preview URL, and is editable. Enter a path or URL and press Enter to navigate | | Refresh | Reloads the preview page | | Open in browser | Opens the current URL in your default system browser | | Device presets | Switches between Mobile, Tablet, and Desktop viewport widths | | Screenshot | Captures the preview and sends the image to the Agent Chat panel | [Table 2. Preview toolbar controls] {#ways-to-preview-an-experience__table-ways-to-preview-an-experience-toolbar-controls} Beyond the three presets, you can drag the resize handles at the edges of the preview frame for a custom viewport width. Dragging the tab's edge resizes the preview against the code editor. Saving a file refreshes the preview automatically through hot module replacement (HMR); the toolbar's Refresh button is for a manual reload. Changes to configuration files such as aiux.json are the exception, those need a dev-server restart to take effect. Logs from the dev server, startup progress, HMR activity, runtime errors, stream into the Console tab of the bottom panel. Linter and type errors appear in Problems, where selecting an error jumps to the offending line; build-pipeline failures appear in Build. For the Lux Lab app that hosts this panel, see [Lux Lab](https://www.servicenow.com/docs/_VNcHMbEYW7b0hyCcNn9zA "Lux Lab is the desktop app for building Lux applications on the ServiceNow AI Platform. It provides Lux aware tooling for scaffolding experiences, pages, and widgets."). ## Preview locally with the dev server {#ways-to-preview-an-experience__ways-to-preview-an-experience-preview-locally-with-the-dev-server} `pnpm dev` starts the full request pipeline on your machine with hot reload: proxy, version router, server-side rendering (SSR) service, and Core UI. You see real server-rendered output, not a static mock. cd my-app pnpm dev Open `http://localhost/aiux//` in your browser. Editing a file under pages/ or components/ recompiles and reloads the app automatically, and the build writes development artifacts to .dev directories. The dev server starts the same layered pipeline as production. The services and their ports are provided in the following table. {#ways-to-preview-an-experience__table-ways-to-preview-an-experience-dev-server-services__entry__3} | Service | Port | Role | |-|-|-| | HTTP proxy | 80 | Entry point for all requests | | Version router | 3000 | Routes to versioned SSR services | | SSR service | 3001+ | Renders your pages server-side | | Core-UI service | 4000 | Serves list, record, and dashboard pages | | Core static server | 4999 | Serves shared widget bundles | [Table 3. Dev server services and ports] {#ways-to-preview-an-experience__table-ways-to-preview-an-experience-dev-server-services} To run more than one app's dev server at once, set `AIUX_INSTANCE` to a number from 1 to 9 before starting it. Setting it shifts the whole port range so the stacks don't collide. `AIUX_INSTANCE=1` moves the proxy from port 80 to 31000 and its services into the 31001+ range, `AIUX_INSTANCE=2` uses 32000, and so on. AIUX_INSTANCE=1 pnpm dev If port 80 requires elevated permissions or is already taken, set `PROXY_PORT` in your .env file instead, and access your app at `http://localhost:/aiux/...`. To diagnose a local setup problem, run the diagnostic tool before digging further: aiux doctor --check It diagnoses and reports common configuration problems. For the automated checks that run against the same code, see [Test an app locally](https://www.servicenow.com/docs/l6r3GV~~GsgjtK91sdlxAg "Testing a page locally with Vitest catches loader and rendering failures before you deploy. Separate unit tests cover your data-fetching logic, and separate render tests cover the HTML your component produces."). ## Preview a production build locally {#ways-to-preview-an-experience__ways-to-preview-an-experience-preview-a-production-build-locally} `pnpm dev` runs an unoptimized dev build. To see what actually ships, the built dist/vN/ bundles, no hot reload, build and serve it locally before you deploy: pnpm build pnpm serve Open the same `http://localhost/aiux//` URL. This is the closest you get to your production artifact without touching a ServiceNow instance. ## Verify server-rendered output {#ways-to-preview-an-experience__ways-to-preview-an-experience-verify-server-rendered-output} Your app can be deployed and running either locally or on an instance. In both cases, the rendered HTML your loader produced appears on the document request's Preview tab in DevToolsNetwork. A blank Preview with a working browser page means your loader is generating an error server-side, check the service logs at `https:///aiux//logs`. Do not confuse this DevTools Preview tab with the Lux Lab Preview panel or the `pnpm serve` command described earlier: three unrelated mechanisms that share the word "preview." The tab inspects one request's rendered HTML; the panel and `pnpm serve` each run your whole app. For deeper inspection of a running page, widget properties, re-render causes, network calls, see ../task/debug-an-experience.html. That topic covers Lux DevTools, a different tool from the browser's built-in DevTools panel described earlier in this topic. Confirming that server-rendered output arrives is also an item on the ship checklist in [Deploy to an instance](https://www.servicenow.com/docs/Q0kWnHyN1pwbeqVQGfFr1g "Getting a change onto a ServiceNow instance is a three-step pipeline: build the app, deploy its records, then verify the service and the app. The same pipeline runs from the command line, from Lux Lab, or ServiceNow Lux Lab for VS Code."). *[\>]: and then