The server capability boundary in a Tauri static app

A Tauri build with output: export does not contain Next.js server routes or redirects. Sharing the same application code does not mean that web and desktop have the same runtime capabilities.

Do not turn a boundary into a mysterious 404

Calling the server-owned /api/batch/init from a static app gives the user an unexplained error. Detect Tauri at runtime, skip the server-owned initialization, and return an explicit state such as unsupported: server-owned-tauri-static.

The UI can explain that the feature runs in the web server and provide the web path. Logs should contain the capability and platform, never tokens or remote endpoint details.

Feature checklist

• List the network and IPC capabilities required by the static export.
• Design loading, unsupported, and retry states for server-owned features.
• Keep window access inside functions so SSR remains safe.
• Freeze the web/Tauri support boundary in tests.

Related course: Close partial failure, recovery, and platform boundaries