Skip to main content
Public beta: AI SRE is in public beta, rolling out gradually to accounts on On-call Pro or higher, at no additional charge during the beta. To get access, submit the AI SRE beta application form. Features and the UI may continue to change.

​
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 includes GitHub, GitLab, and Kubernetes Apps. GitHub and GitLab authorize access to code repositories: AI SRE can read code, investigate changes / commits / PRs (MRs on GitLab), and, when asked, fix a bug or open a PR / MR or issue. A Kubernetes App connects a selected Kubernetes cluster to AI SRE and limits the agent to the configured namespaces and permission level.

​
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.

​
Kubernetes Apps

A Kubernetes App connects an in-cluster agent to AI SRE. After installation, AI SRE can query cluster information and use the available Kubernetes tools within the namespaces and permission boundaries you configure.

​
Create and install

1

Create a Kubernetes App

Go to Plugins → Apps → Kubernetes Apps and click Create Kubernetes App. Enter a cluster name and choose its scope: Shared is available to all sessions in the account; Team is available to that team’s sessions and to personal sessions of its members. Cluster names must be unique within a scope.
2

Set namespace access

Choose All namespaces or Specific namespaces. All namespaces applies one permission level to current and future namespaces. With specific namespaces, set Read-only, Read + limited modifications, or Full access for each namespace. Leaving the specific-namespace list empty allows the agent to read only basic cluster metadata. Full access for a specific namespace allows every operation on every resource in that namespace while basic cluster metadata remains read-only. Full access for all namespaces grants cluster-admin, including access to cluster-scoped resources and cluster RBAC.
3

Run the installation command

Save the App, copy the generated installation command, and run it in the target cluster. Installation commands expire; reopen the installation setup or view the manifest to generate a new command without rotating the token.
After changing namespace access or permissions, run the installation command again so the in-cluster RBAC is updated. Before choosing Read + limited modifications, confirm that AI SRE is allowed to perform those actions in the namespace. Full access can read, create, change, and delete resources; read and change ConfigMaps and Secrets; enter or attach to containers; forward ports; and change namespace RBAC. Use it only when it is necessary and has passed your access review.

​
Edit and revoke

You can edit the cluster name, scope, and namespace access from the Kubernetes App list. Revoking immediately invalidates the connection and token, but it does not remove the in-cluster agent or RBAC automatically. Run the uninstall command shown by the console in the target cluster. It removes only resources for this Kubernetes App and preserves the shared flashduty namespace.

​
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.