Skip to main content
Private beta: AI SRE is currently in private beta. Pro or higher accounts can apply for free beta access through the AI SRE private beta application form; after approval, Flashduty will add your account to the whitelist. Features and the UI may change during the beta.

​
Overview

Apps is where you manage authorized external applications. Each external application appears as a card — you authorize it, manage its installations, and enable / disable or revoke it right from its card. Apps today has two applications — GitHub and GitLab — covering the most common code-hosting platforms. Once you authorize one, AI SRE can work directly inside your code repositories during a session: understand and explore code, investigate recent changes / commits / PRs (MRs on GitLab), trace a PR / MR from a change ticket, answer questions about a codebase, and — when you ask — fix a bug, open a PR / MR, or file an issue. It all runs through native gh / glab / git, like an engineer working in a terminal.

​
Main Scenario: Letting the Cloud Sandbox Reach Your Repositories

AI SRE sessions run in a Flashduty cloud sandbox by default. The sandbox is a clean, isolated, ephemeral environment that carries none of your git credentials — which is exactly what an App solves. Once you authorize the GitHub App or the GitLab App, the agent inside the sandbox can clone your repositories, read diffs, and open PRs / MRs, without you handing it any password or token; its access is limited to the repositories you granted, with only the least privilege needed to do the work. This is what both Apps are mainly for.
BYOC (self-hosted Runner) generally doesn’t need it. A Runner runs on your own machine, which usually already has gh / glab / git credentials configured (you work with repositories on it every day). In that case the agent just uses the host’s own credentials — no App authorization needed. (If the host happens to have no credentials configured, authorizing the App lets BYOC sessions use it too.) For the differences between environments, see Environments (BYOC).

​
Where to Find It

Go to Plugins → Apps. Apps is the first and default tab in the Plugins area — opening Plugins lands you here.
Viewing the Apps tab requires the appropriate permission; without it, the tab is hidden. Authorizing, disconnecting / revoking, and enabling / disabling each require their own action permission — when you lack one, the corresponding button is shown disabled.

​
The GitHub App

The following walks through GitHub first — authorization, installation management, and adjusting repository access; GitLab follows in the next section.

​
Connecting a GitHub Organization

Start the authorization from the GitHub card. The whole install completes in a popup through GitHub’s official install page, and the list refreshes automatically after the callback.
1

Start the authorization

Click Authorize on the GitHub card (if the App already has an installation, the button reads More repositories, with a + icon). The frontend opens a popup that loads GitHub’s official install page.
2

Pick the organization and repositories on GitHub

Choose the organization (or personal account) to install into, and grant a repository scope — All repositories or Only select repositories. The set of granted repositories determines which repositories AI SRE can access afterward.
3

Auto-refresh after you confirm

After you confirm on GitHub, the popup closes automatically, the Apps page shows Authorized and refreshes the installation list, and the new organization appears.
If you are not the owner of the organization, GitHub routes the request to the organization owner through its request-to-install approval flow; the installation activates only after approval. Which organization to install into and which repositories to grant are decided entirely on GitHub’s install page — Flashduty does not select on your behalf.

​
Managing Installations

Each authorized organization adds one installation row under the GitHub card. Each row shows:
The toggle in the top-right of the card switches between Enabled and Disabled. Disable = suspend: while suspended, the agent can no longer reach those repositories — but the GitHub installation itself is kept, so you can re-enable instantly with one click, without going through the GitHub authorization again. An App counts as “enabled” as long as it has at least one Connected installation.
Click Revoke on a row; after you confirm, the installation is set to Revoked and AI SRE can no longer access that organization’s repositories. A revoked installation is hidden from the card; re-authorizing the same organization restores it.
Suspend vs. Revoke: suspend turns it off temporarily, keeps the GitHub installation, and resumes with one click; revoke disconnects this authorization and requires going through the GitHub authorization again to use it.

​
Adding or Adjusting Repository Access

The organization is already connected, but you want AI SRE to reach more of its repositories — you don’t need to revoke and reconnect. In Plugins → Apps, click More repositories again for that organization (or open the App’s Configure page on GitHub directly). GitHub shows the Repository access screen; select the additional repositories and save, and AI SRE re-syncs the granted repository list automatically — the new repositories become available without re-creating the connection.
Fallback: if a newly added repository still reports “cannot access / 404 / 403” in a session, open the App’s page on GitHub (e.g. github.com/apps/flashduty) → Configure → select the organization → scroll to the Danger zone → Uninstall. Then return to Plugins → Apps in Flashduty and authorize the organization again, granting all the repositories you need in one pass.

​
The GitLab App

The GitLab App connects a GitLab instance — GitLab.com, JihuLab (GitLab’s China distribution, SaaS at jihulab.com or a private deployment), or any other self-managed instance of your own. The connection method is exactly the same for all of them: register an OAuth application on that instance first, then authorize. Once authorized, AI SRE can read code and investigate changes / MRs, and — when you ask — file an issue or open an MR, in the repositories you authorized. Just like GitHub, you never paste a personal token: once Flashduty gets an OAuth grant, it provisions a dedicated bot identity for your account to do the actual work.

​
Connecting a GitLab Instance

1

Choose the GitLab instance to connect

Click Connect on the GitLab card and pick one of three options:
  • GitLab.com — the address is fixed to https://gitlab.com; nothing to fill in.
  • JihuLab — the address is fixed to https://jihulab.com; nothing to fill in.
  • Self-managed — enter the instance’s root address: the part of the URL before the group / project path, for example https://gitlab.example.com. If the instance is deployed under a subpath, include it, for example https://example.com/gitlab.
2

Choose the connection environment

Network requests for connecting and re-authorizing GitLab are issued from the environment selected here. Public instances such as GitLab.com and JihuLab can use the default cloud environment. For a self-managed instance reachable only from a private network, choose the BYOC Runner that can reach it. The system does not automatically switch environments when a Runner is offline or unreachable; choose an available environment and start the connection or authorization again.
3

Register an OAuth application on that instance

The connect wizard shows a copyable Redirect URI. Take it to the GitLab instance you entered and create an OAuth application: a group Owner does this under Group Settings → Applications; on GitLab.com, if you’re not the Owner of any group, a user-owned application under User Settings → Applications also works; an instance admin can also register one under Admin Area → Applications. Fill in the Redirect URI the wizard gave you, check Confidential, and check only the api scope. GitLab then issues an Application ID and a Secret — paste both back into the wizard.
This step is the same for every GitLab instance — GitLab.com, JihuLab (jihulab.com SaaS or a private deployment), or any other self-managed instance: only the address changes, registering the OAuth application and pasting the Application ID / Secret works identically everywhere.
4

Authorize in the popup

This step shows which instance and which OAuth application it’s about to authorize with; if you want to use a different application, click Change OAuth application to go back and register a different one. Once you confirm, the wizard opens a popup that loads GitLab’s official authorization page; sign in with your GitLab account and confirm. The popup closes automatically once authorization completes, and the wizard advances to the next step.
5

Pick the groups and projects to authorize

AI SRE shows a repository picker listing the groups where you have the Owner role and the projects where you have the Maintainer role. Select the groups / projects you want AI SRE to access and save — selecting a group covers all of its projects, including ones created later.
An account can connect only one GitLab instance at a time (GitLab.com or one self-managed instance). To switch to a different instance, disconnect the current one first.

​
Bot Identity and Permissions

After you save the repository selection, Flashduty provisions a dedicated bot for the account inside those groups / projects (a service account where the instance supports it, falling back to a group- or project-level access token otherwise) for AI SRE sessions to use. Either way, the bot’s permissions are capped at Developer level — the same minimum access you’d grant it in GitLab yourself. Tokens are rotated automatically before they expire; there’s nothing for you to manage. If the instance doesn’t support service accounts, the bot falls back to a group- or project-level token — and a token like that can only ever bind to a single group or project, so the repository picker limits you to selecting at most one group or project. If you select multiple groups / projects while in multi-select mode and save, Flashduty shows “This GitLab instance doesn’t support service accounts; select only one group or project and retry,” and switches the picker to single-select mode: checking a new group or project after that automatically clears any other selection, so you need to leave just one group or project checked before saving again.
One restriction on GitLab.com: GitLab’s own policy limits group- and project-level access tokens to paid (non-free, non-trial) namespaces. Connecting GitLab.com itself is unaffected, but if the group / project you authorize lives in a free or trial namespace, bot provisioning fails and the UI shows GitLab’s own explanation (“provisioning_denied”). Upgrade that namespace to a paid plan and re-authorize to resolve it.

​
Managing a Connected Instance

The GitLab card shows the connected instance’s address and status.
Reopens the repository picker so you can add newly needed groups / projects or remove ones you no longer need — AI SRE’s access updates as soon as you save.
Disconnects this instance. Flashduty makes a best effort to clean up the bot identity provisioned for the account and any tokens under it; if a cleanup step doesn’t succeed, the UI surfaces a warning. All access to the instance stops immediately after disconnecting, and reconnecting requires going through OAuth authorization again.

​
How AI SRE Works Inside a Repository

After authorization, you need no extra configuration. When you ask AI SRE to work on a task in a repository during a session, it works like an engineer joining the project — understand first, then change, then verify. This behavior is governed by the built-in github Skill and gitlab Skill respectively. Typical actions
  • Enter the repository: clone it into its own workspace and read the repo’s own conventions first (CLAUDE.md, AGENTS.md, README, CONTRIBUTING).
  • Investigate changes / PRs / MRs: use git log, plus gh pr list / gh pr view / gh pr diff / gh search prs on GitHub, or the equivalent glab mr list / glab mr view / glab mr diff on GitLab, to trace a PR / MR named in an incident or change ticket, see what a release shipped, or read a diff before deciding anything.
  • Change and propose: create a branch, make a minimal diff, open a reviewable PR / MR with gh pr create or glab mr create, or file an issue with gh issue create / glab issue create, and report the link back to you.
Hard guardrails — the agent never crosses these:
  • Never force-push (git push --force), and never push the default branch directly — always a branch + PR / MR.
  • One logical change per PR / MR, kept reviewable; if a change balloons beyond a focused diff, it stops and hands the analysis back to you.
  • Never delete branches, close others’ issues / PRs / MRs, or change repository settings; never commit secrets, credentials, or build artifacts.
If the agent reports it cannot access a repository in a cloud session, it usually means the account has not authorized the relevant App (GitHub or GitLab), or the target repository / group was not granted — just authorize and grant it under Plugins → Apps. The agent does not ask you for any token.

​
Permissions & Scope

Authorize and revoke / disconnect are account-level operations for both the GitHub App and the GitLab App. The account is the only security boundary; the team here is just an ownership / audit tag: any account member with the corresponding permission can authorize, revoke / disconnect, or enable / disable the whole App; when a session needs a repository, it obtains access from the account’s currently active installation. Members of an account share one authorization — consistent with AI SRE’s “usage = account-level, ownership = team tag” model for other resources. The two Apps’ scope models differ slightly: the GitHub App lets the same account install multiple organizations, each enabled / revoked independently; the GitLab App lets an account connect only one GitLab instance at a time — switching to a different instance requires disconnecting the current one first.

MCP (External Tools)

Connect external tools and data sources via the Model Context Protocol.

Console

Watch the agent clone a repo, read a diff, and open a PR / MR during a session.

Environments (BYOC)

BYOC sessions use the runner host’s own credentials and generally don’t need the GitHub / GitLab App.

Skills

The built-in github / gitlab Skill governs how the agent works inside a repository.