Mount Points

Mount points are the URL paths declared in the mountPoints object of telemetry.config.json. They tell the platform where to load each browser-based component of an application: render on devices, settings in the Studio sidebar, and web in a standalone browser tab. Each mount point maps to an HTML entry point produced by the build.

Workers and containers are also part of the application component model, but they are not mount points — they use separate configuration blocks and are documented in their own pages: Workers and Containers.

The Three Mount Points

The render mount point is the visual content that appears on physical devices — menu boards, dashboards, kiosk interfaces, or any other screen experience. It runs inside an iframe on the device and in the Studio preview, with full SDK access to all four storage scopes, media, playlists, and hardware. Render is the only required component.

The settings mount point provides the configuration interface that appears in the Studio sidebar when an administrator selects an application instance in a playlist. Settings views write to instance storage, allowing the same application to behave differently on different screens without code changes.

The web mount point is a browser-accessible interface that runs outside Studio and the device player entirely. Staff, operators, or the public access it directly via URL on phones, tablets, and desktops. Unlike render and settings, the web view has no instance or device context — it uses application-scoped and shared storage only.

Configuration

Mount points are declared in the mountPoints object of telemetry.config.json:

{
  "name": "restaurant-menu",
  "version": "1.0.0",
  "useSpaRouting": true,
  "mountPoints": {
    "render": "/render",
    "settings": "/settings",
    "web": "/restaurant-menu"
  }
}

Each key maps a component type to a URL path. During the build, your build tool (typically Vite) produces an index.html at each path, and the platform loads those entry points in the correct context. The web path must match the application name, and useSpaRouting must be true when using the web mount point.

Comparison

Lifecycle

When a playlist containing an application is loaded on a device, the platform creates the render iframe when the playlist page becomes visible. The settings iframe is created only when an administrator opens the configuration panel in Studio. The web view has an independent lifecycle — it loads when someone navigates to its URL and stays active as long as the browser tab remains open.

The render iframe is destroyed when the playlist rotates away from the page containing the application and recreated when it returns. Settings and web iframes persist for the duration of their browser session.

Data Flow

The three mount points communicate through the SDK's storage API. The typical pattern is straightforward: settings writes configuration to instance storage, and the render view subscribes to those changes and updates the display in real time. The web view shares data through application-scoped storage.

Settings (admin configures) → instance storage    → Render (displays on device)
Web (staff updates)         → application storage  → Render (displays on device)

Changes propagate in real time across the network — no polling, no manual refresh.

Testing Locally

The tos dev command opens your project in the Developer App, which simulates the platform environment. Render and settings mount points display within the app window. Storage operations persist locally so you can test communication between components.

Detailed Documentation

Each mount point has its own page covering configuration, runtime context, code examples, and best practices:

• Render — Display content on devices
• Settings — Configuration interface in Studio
• Web — Browser-accessible interface for staff and public use

For the complete telemetry.config.json reference, see Configuration.