---
title: Desktop app
description: What Multica Desktop is, how it differs from the web app, and when it's worth using.
---

import { Callout } from "fumadocs-ui/components/callout";

Multica Desktop is a native desktop app for macOS, Windows, and Linux. For the environment it is configured for, it talks to the same backend as the web app and shows the same data. By default Desktop uses Multica Cloud; self-hosted instances can be configured with a local runtime config file. Desktop also adds a few things the browser can't: **independent tab groups per [workspace](/workspaces)**, **automatic [daemon](/daemon-runtimes) startup**, and **one-click upgrades**.

## Desktop or web — which to pick

| | Web | Desktop |
|---|---|---|
| Access | Open a URL in your browser | Install a native app |
| Multiple tabs | Your browser's own tabs (no workspace separation) | **One independent tab group per workspace** |
| Daemon | You run `multica daemon start` yourself | **Started automatically** on launch |
| Upgrades | Refresh to get the latest | App checks in the background and installs on next launch |
| Signed-in data | Identical | Identical |

**Pick web** for one-off use, working on someone else's machine, or when you'd rather not install anything.
**Pick desktop** for daily use, juggling multiple workspaces, or avoiding manual daemon management.

## Multiple tabs: what happens when you switch workspaces

Desktop maintains an independent tab group for **every workspace you've joined**. When you switch workspaces, the current workspace's tabs are hidden as a unit and the previous workspace's tabs are restored as you left them — similar to VSCode's multi-workspace behavior or switching workspaces in Slack.

Example: you open 3 issue tabs in workspace A and switch to workspace B. A's 3 tabs disappear, and B shows whatever you last had open in B. Switch back to A and those 3 tabs come back exactly as they were. **Tabs never leak across workspaces.**

Logging out **clears every workspace's tab state**, so you don't leak data when a machine is shared between users.

## How Desktop auto-updates

On launch, Desktop checks GitHub Releases for a newer version. If one is found:

1. It downloads the new version silently in the background.
2. It tells you "ready — will install on next launch."
3. When you quit (or next restart), the app installs the update before closing.
4. The next launch runs the new version.

The whole process **doesn't interrupt what you're working on**.

<Callout type="warning">
**On Windows, ARM64 and x64 are separate update channels** — install the wrong architecture and updates won't be detected. When you download, pick the `.exe` that matches your machine (the ARM build has an `arm64` suffix).
</Callout>

The macOS build is signed and notarized, so you won't see an "unidentified developer" warning on first launch. The Linux build is an `.AppImage` — auto-updates rely on electron-updater, which can be flaky on some distros. **If auto-update doesn't work, download the new version manually and replace the old file.**

## Do I still need the standalone CLI and daemon?

**No.** Desktop ships with the same `multica` CLI binary embedded inside it, and it launches its own daemon profile at startup (isolated from any daemon you may be running manually from the terminal).

If you've already installed the CLI and run `multica daemon start` by hand, Desktop won't take over your daemon — it starts its own with a separate profile. Both register as **different runtimes**, and you'll see two independent runtimes in the UI.

If you want to run CLI commands in your terminal, Desktop doesn't offer a special path — use the CLI you installed separately, or run the bundled copy at `resources/bin/multica` inside the app's resources directory.

## Downloading and installing

Grab the installer for your platform from the [Multica downloads page](https://multica.ai/download):

| Platform | File |
|---|---|
| macOS (Intel or Apple Silicon) | `.dmg` |
| Windows x64 | `.exe` (standard) |
| Windows ARM64 | `.exe` (with `arm64` suffix) |
| Linux | `.AppImage` |

On first launch you'll need to sign in — the same email + verification code flow as the web app. Once you're in, Desktop syncs your workspace list automatically.

<Callout type="info">
**Desktop defaults to Multica Cloud, but can be pointed at a self-hosted instance with a local config file.** There is still no in-app "connect to self-host" picker. Desktop reads `~/.multica/desktop.json` before the renderer starts; if the file is missing, it uses the Cloud defaults.

Minimal self-host config:

```json
{
  "schemaVersion": 1,
  "apiUrl": "https://api.your-domain"
}
```

`apiUrl` is required and must use `http` or `https`. Desktop derives `wsUrl` as `/ws` on the same origin (`wss` for `https`, `ws` for `http`) and derives `appUrl` from the API origin. If your deployment uses different origins, set them explicitly:

```json
{
  "schemaVersion": 1,
  "apiUrl": "https://api.your-domain",
  "wsUrl": "wss://api.your-domain/ws",
  "appUrl": "https://your-domain"
}
```

If `desktop.json` exists but is invalid, Desktop fails closed and shows a blocking config error instead of silently falling back to Cloud. For development builds, `VITE_API_URL` / `VITE_WS_URL` / `VITE_APP_URL` still take precedence during `electron-vite dev`. Runtime Desktop self-host configuration was implemented for [issue #1371](https://github.com/multica-ai/multica/issues/1371).
</Callout>

## Next steps

- [Cloud Quickstart](/cloud-quickstart) — the Cloud onboarding flow for Desktop
- [Self-Host Quickstart](/self-host-quickstart) — running your own backend and connecting with the CLI or Desktop runtime config
- [Daemon and runtimes](/daemon-runtimes) — how the daemon works (Desktop starts it for you, but the behavior is the same)
