Local instances

Prepare the computer

Use a dedicated clone for evaluation with Node.js 24, pnpm 10.28.0, Git, Supabase CLI and a running Docker daemon. Allow at least 4 GB free RAM, two CPU cores and 10 GB free SSD; 8 GB, four cores and 20 GB are recommended. Install the signed desktop app from the download page first. Windows uses Microsoft Store; macOS and Linux use their platform downloads. Pin the clone to the release you intend to evaluate before installing its dependencies.

git clone https://github.com/mangue-dev/minddy.git
cd minddy
git checkout v0.20.0
corepack enable
corepack prepare pnpm@10.28.0 --activate
pnpm install --frozen-lockfile

Choose the personal installation when the desktop app will manage the local services.

New local installations encrypt workspace content by default. To record an explicit choice, run pnpm bootstrap:supabase -- --minimal --app-url http://localhost:6463 --encryption enabled (or --encryption disabled) in the clone before opening it in the app; later starts keep the saved choice. See workspace encryption.

Let the app own the local services

Open the native minddy menu. On Windows and Linux, press Alt to reveal the menu bar; macOS uses the global menu bar. Choose the server connection dialog, then its local-instance option and select the clone root. The app invokes self-host:local --no-open, prepares minimal Supabase, applies migrations and Storage configuration, builds when needed and waits for /api/health before opening sign-up. The app binds to loopback port 6463, remembers the folder and owns both startup and shutdown.

MCP availability and network access

MCP is included in self-hosted minddy and starts with the application. It works out of the box at /api/mcp on the instance origin configured with MINDDY_PUBLIC_APP_URL. OAuth discovery and dynamic client registration are included: you do not need a separate MCP server, a dedicated OAuth application or a minddy Cloud proxy. Connect your MCP client to your instance endpoint, then sign in and grant access through the browser consent flow.

Availability does not guarantee network reachability. Both the MCP client and the browser used for authorization must be able to reach the advertised MCP and OAuth URLs. If you configure an explicit OAUTH_ISSUER override, that origin must also be reachable. The client must support the connection, OAuth flow and chosen network path; some clients require HTTPS even on private networks.

This desktop-managed profile listens only on loopback. A compatible MCP client on the same computer can use http://localhost:6463/api/mcp; localhost and 127.0.0.1 refer to the computer making the connection. Another computer or a hosted/cloud agent cannot reach this profile directly. For LAN/VPN access, use a server installation with a reachable configured origin, for example http://192.168.1.50, and allow its application port through the listening address, firewall and routing. Outside that network, the client needs a reachable HTTPS origin such as https://tickets.example.com, or another supported network path. Local installation does not automatically provide Internet access.

Read the MCP network guidance before connecting a remote client.

Recover a failed launch

Closing a window leaves the desktop application running; use the application’s Quit command to stop it and the local services. Check Docker, CLI availability, free space and whether port 6463 belongs to another process. pnpm self-host:local is a terminal troubleshooting fallback. Stop it with Ctrl+C before returning control to the app; the app refuses to claim another process. Quitting the app normally stops Supabase too. The --keep-backend option deliberately changes that behavior. Never use supabase db reset --local as recovery: it destroys evaluation data. Verify a new account, project, issue and attachment before relying on the instance.