# Overview (/web/installations) Installations are the GitHub App coverage layer behind Mogplex repo automation. There is not a separate top-level `/installations` dashboard route today. This docs section describes the GitHub App installation state surfaced in [Settings](/web/settings) and consumed by [Projects](/web/spaces), [Triggers](/web/triggers), and [Automations](/web/automations). ## The distinction to keep explicit [#the-distinction-to-keep-explicit] For most setup problems, there are three states a repo can be in: 1. **not visible at all** 2. **visible through GitHub OAuth** 3. **covered by a Mogplex GitHub App installation** Only the third state is fully eligible for App-backed routing and automation. That is why Installations deserves its own docs section even though the product does not currently expose it as a standalone top-level dashboard page. ## Why installations matter [#why-installations-matter] An installation answers two different questions: 1. which account or org has granted the Mogplex GitHub App access 2. which repos are therefore eligible for App-backed behavior That second point is the important one. A repo can be visible through OAuth and still not be triggerable. ## OAuth vs installation coverage [#oauth-vs-installation-coverage] Keep this distinction explicit: * **GitHub OAuth** gives Mogplex an authenticated user identity and supports repo discovery * **GitHub App installation** gives Mogplex webhook-backed coverage for the installed account or org That is why a repo can appear in [Projects](/web/spaces) yet still fail to participate in [Triggers](/web/triggers) or installation-backed automations. ## What “covered” unlocks in practice [#what-covered-unlocks-in-practice] When the right installation exists, Mogplex can do more than just list repos. It can: * receive webhook events for the installed owner * offer that installation as a routing target in [Triggers](/web/triggers) * treat repos under that owner as eligible for App-backed workflows * reconnect synced repos to the correct owner and installation metadata ## What the app surfaces show [#what-the-app-surfaces-show] Inside [Settings](/web/settings), each installation can show: * the account or org name * whether the scope is personal or org * the synced repos Mogplex currently associates with that installation * how many repos are mapped to it * a direct manage link back to GitHub This is the fastest way to answer the real operator question: **Do I have the right App installed on the right owner, or am I only seeing repos through OAuth?** ## How Mogplex keeps installation state fresh [#how-mogplex-keeps-installation-state-fresh] The installations API is a little self-healing. If Mogplex has GitHub App config and your GitHub username, but there are no stored installations yet, it can reconcile against GitHub again and hydrate the local installation records before returning the Settings view. It can also refresh incomplete installation metadata, such as missing account login or target type, and then derive: * a scope label like `Org` or `User` * the GitHub manage URL for that installation That is why the Settings page can often recover from stale installation records without asking you to reconnect everything manually. ## The most reliable workflow [#the-most-reliable-workflow] 1. Connect GitHub in [Settings](/web/settings). 2. Confirm the expected personal account or org appears in the installation list. 3. Sync repos into [Projects](/web/spaces). 4. Only after that, debug [Triggers](/web/triggers) or [Automations](/web/automations). If you skip step 2, you can spend time debugging a routing problem that is really just missing GitHub App coverage. ## Common symptoms of missing coverage [#common-symptoms-of-missing-coverage] * the repo appears in [Projects](/web/spaces), but [Triggers](/web/triggers) offers no useful installations * mention or PR-triggered work never fires even though the repo is visible * webhook-backed automation looks empty or unavailable for the owner you need * the app appears connected, but Mogplex still behaves as if the repo is “outside” the GitHub App boundary ## In this section [#in-this-section] * [Coverage and Triggerability](/web/installations/coverage-and-triggerability) explains the “repo is visible but not triggerable” setup model * [Repo Sync and Rebinding](/web/installations/repo-sync-and-rebinding) explains how repos are attached to installations and how stale bindings get repaired ## Where installations show up in the product [#where-installations-show-up-in-the-product] * [Settings](/web/settings) is the main inspection surface * [Projects](/web/spaces) shows the repos that were imported or synced * [Triggers](/web/triggers) only offers installations that are actually available for webhook-backed routing * [Automations](/web/automations) depends on installation-backed GitHub events If routing or review behavior looks wrong, check installation coverage before you debug the agent or automation itself.