Cloud and self-hosted instances
Compare who operates the service, where data goes, and which optional providers you configure.
Choose an operating model
minddy Cloud and self-hosted minddy run the same public core. Choose Cloud if you want minddy to operate the application, database, Storage and scheduler. Choose self-hosting if you need to select the hosting location, providers or upgrade schedule and can operate those services yourself.
A Cloud account belongs to Cloud. On a self-hosted instance, create an account on that instance; a minddy Cloud account is not a prerequisite. Check the address before signing in or inviting someone. Accounts and credentials do not become shared merely because two instances run minddy.
Responsibilities and costs
| Responsibility | Cloud | Self-hosted |
|---|---|---|
| Infrastructure, updates and incidents | minddy operates the service. | You maintain the hosts, TLS, monitoring and release upgrades. |
| Backups and recovery | minddy operates the Cloud service. | You preserve database data, Storage bytes, configuration and encryption keys, and rehearse restores. |
| Provider accounts | minddy owns the accounts for services it operates. | You choose and pay for infrastructure and optional providers. |
| Support | Cloud support terms apply. | Release tooling and best-effort community help cover reproducible core defects; infrastructure operation has no included SLA. |
For example, a team without database operations capacity can use Cloud. An operator with data residency requirements can choose self-hosting and review each enabled provider's data destinations. Running the application yourself does not make an external AI, email or Git provider local.
Required and optional services
A supported self-hosted installation needs the application and Supabase with PostgreSQL, Auth, Storage and Realtime. PostgreSQL alone is insufficient. Use a tagged release and its compatibility matrix. Unpinned derivative Supabase stacks and self-managed GitHub Enterprise or GitLab adapters are outside the supported contract.
AI, email, Git, push notifications and analytics depend on configuration. Self-hosting does not require Stripe, PostHog, a minddy-managed AI key or a Cloud account. Missing optional configuration is reported rather than replaced silently with a provider. Personal AI keys and, in the desktop app, local AI endpoints are possible choices; their availability and costs depend on the configured capability.
Review provider permissions and data terms before enabling an integration. Git connections may use the managed forge relay when you explicitly start the integration; operator-owned provider applications and relay opt-out are also available. Core feature access is not a separate reduced self-hosted tier.
Source and next step
The canonical source is mangue-dev/minddy, under GNU AGPL v3.0 only. Keep the license and naming policy in mind for modified or hosted deployments. For installation, start with the step-by-step self-hosting installer. Use the installation reference for technical details and additional checks. Before transferring existing work, check the account-data transfer guide: credentials and subscriptions are not transferred with account data.