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.
Table of contents
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.
Responsibilities by runtime
Runs features that need a server lifecycle, such as route handlers, auth, and batches.
Uses built assets and explicitly allowed remote APIs only.
Adds approved file, SQLite, and OS capabilities to the static surface.
Treat unsupported as guidance to an available path, not as a retrying outage.
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.
Verdict by platform
| Capability type | Web SSR | Static web | Tauri | Failure UX |
|---|---|---|---|---|
| Server Route Handler | Available | Unavailable | Unavailable | Link to the web path |
| Public remote API | Available | Available | Available when allowlisted | Separate network and permission errors |
| Local files or SQLite | Unavailable | Unavailable | Available with permission | Explain setup or permission |
| Background scheduler | Server-owned | Host-dependent | Bound to app lifecycle | Show last execution time |
type CapabilityResult<T> =
| { status: "available"; value: T }
| { status: "unsupported"; reason: "server-owned-tauri-static" }
| { status: "failed"; retryable: boolean };
unsupported is not an outage, so it must not trigger endless retries or error alerts. Keeping it separate from failed prevents users from trying to repair their installation and keeps platform differences out of incident metrics.
Feature checklist
- List the network and IPC capabilities required by the static export.
- Design loading, unsupported, and retry states for server-owned features.
- Keep
windowaccess inside functions so SSR remains safe. - Freeze the web/Tauri support boundary in tests.
Related course: Close partial failure, recovery, and platform boundaries