Connect an integration

An integration is a connection to a tool you already use, so Halon, investigations and the AI agents you connect can read from it and act in it during an incident. Connecting one never turns anything on by itself. Firefight discovers what the tool can do, and you pick which of those capabilities to allow.

Go to Configure → Integrations to see the catalog. Connecting and managing integrations requires admin access.

What you can connect

The catalog groups providers by what they are. Choose the info button on a card to see what Halon does with that provider, whether it puts what it runs on the resource map, and what it may change. What Halon can do covers the same ground for every group.

Category	Integrations
Cloud and hosting	AWS, Azure, Cloudflare, Convex, DigitalOcean, Fly.io, Google Cloud, Kubernetes, Modal, Netlify, Northflank, Railway, Render, Trigger.dev, Vercel
Observability	Axiom, Better Stack, Datadog, Grafana, Honeybadger, Honeycomb, Logfire, New Relic, OpenStatus, Sentry, SigNoz
Alerting and on-call	Opsgenie, PagerDuty
Product analytics	Mixpanel, PostHog
Databases	ClickHouse, Neon, PlanetScale, PostgreSQL, Supabase, Tinybird, Turso, Upstash
Code	Azure DevOps, Bitbucket, GitHub, GitLab
CI	CircleCI
Coding agents	Cursor, Devin, Factory
Issues	Jira, Linear
Knowledge	Confluence, Notion
Status pages	Statuspage, Instatus
Custom	Any MCP server

Use the search box above the catalog to find a provider by name, category or description. Once something is connected, the Connected and Disconnected filters narrow the list.

If the tool you want is not listed but speaks Model Context Protocol, connect it with Custom MCP server and point Firefight at its URL. The server must be reachable on a public address. Firefight refuses one on a private network unless whoever runs your Firefight allowed it. Everything else on this page works the same for it.

Connecting

Click Connect on the integration you want. How it connects depends on the provider.

How it connects	Integrations
One click, on the provider’s own consent screen	Axiom, Better Stack, ClickHouse, Cloudflare, Confluence, Datadog, Grafana, Honeybadger, Honeycomb, Jira, Logfire, Mixpanel, Neon, New Relic, Notion, OpenStatus, PagerDuty, PlanetScale, PostHog, Sentry, SigNoz, Supabase, Turso, Upstash
Installing Firefight’s app	GitHub, Linear
Credentials pasted into the form	AWS, Azure, Azure DevOps, Bitbucket, CircleCI, Convex, Cursor, Devin, DigitalOcean, Factory, Fly.io, GitLab, Google Cloud, Instatus, Kubernetes, Modal, Netlify, Northflank, Opsgenie, Railway, Render, Statuspage, Tinybird, Trigger.dev, Vercel
A server address and an access key	Custom MCP server, and a Grafana you run yourself
A connection address	PostgreSQL

One click

For a provider that hosts its own MCP server, click Continue with and the provider’s name, approve access on that tool’s own consent screen, and land back in Firefight connected. There are no keys to copy and nothing to paste. When a provider runs in more than one region, such as a US and an EU site, the dialog asks which one your account is in first.

The consent screen belongs to the tool, not to Firefight, so it is the right place to narrow access. PlanetScale, for example, asks you to tick which organizations and databases to grant.

Supabase’s connect form asks for Access, Read-only or Read and write. A read-only connection offers no tool that changes the database or the project, so Halon cannot restart a Supabase project or restore its database through it.

If you would rather use a token, choose Use a token instead. Paste the server’s address into Server address, and the key into Access key (sent as the Authorization header) as Bearer followed by the key. A read-only key is best where the tool offers one. A custom MCP server always connects this way. A token is used only by that one connection, never shown again after you save it, and never sent to agents.

ClickHouse, Neon, Turso and Upstash ask for their key in plain fields instead of a header, with the server address already filled in. Fill in every field and choose Connect & discover tools. Some of what Halon does there reaches the provider’s own API, which needs a key. A connection made by signing in still reads everything the provider’s server offers, and Halon tells you to connect again with Use a token instead when it needs a key.

Provider	Fields	What needs the key
ClickHouse	Key ID and Key secret, from ClickHouse Cloud’s organization settings, API keys	Scaling, starting or stopping a service, and reading the organization’s activity log. The key’s role has to allow each one
Neon	API key, an organization API key from your organization’s Settings, API keys	Restoring a branch to a moment, and reading a project’s consumption
Turso	API token, a Platform API token scoped to your organization, made with turso auth api-tokens mint and its --org flag	Reading a database’s usage, when Turso does not take the sign-in for it
Upstash	Email and API key, a Developer API key from the Upstash console’s Account, API Keys, with the email of the account it belongs to	Restoring a Redis database from a backup

Make the token from an identity that is not one person wherever the tool has one, such as a service account, an organization or account token, or a dedicated user named Firefight. Changes Halon makes then show under that name rather than a teammate’s, and the connection keeps working when someone leaves. Where a tool has one, the connect dialog names it under the token field. A tool that reads its key from a header of its own names that header on the field, such as Access key (sent as the x-openstatus-key header) for OpenStatus, and you paste the key alone.

PlanetScale’s form also has a Service token ID field. With a service token, paste its secret alone after Bearer and put the token’s id in Service token ID. Firefight needs the id to read deploy requests and branch changes and to add its own webhooks, see PlanetScale live updates. Leave it empty when you sign in. A token connection without the id still reads everything PlanetScale’s server offers, and the tools that need the id say so. To add the id later, open the connection under Integrations, find Service token ID under Credentials and choose Add. Paste the id and choose Save, and Firefight checks the connection again with it. Change replaces it, and saving it empty clears it.

Caution

Whatever you leave unticked on a consent screen, Firefight cannot reach later. If a capability keeps failing with a permissions error from the tool, reconnect and check what you granted there.

GitHub

GitHub connects by installing Firefight’s app. Click Continue with GitHub and choose which repositories it covers on GitHub’s install screen. GitHub then asks you to authorize Firefight, which lets Firefight check that the installation is one your GitHub account can manage. Install the app on an account you manage. An installation your account cannot manage is refused with a message saying so, and nothing is connected.

Each capability needs a permission in Firefight’s GitHub App.

Permission	Capabilities that need it
Contents read	commit_lookup, fetch_file, blame, compare_commits, changes_before, running_commit, run_workflow, list_releases, release_lookup, list_branches, branch_protection and the capabilities that read code (list_files, code_search, find_definition, find_usages, git_log, show_commit, diff_refs, ask_language_server, run_shell, run_tests)
Contents read and write	merge_pull_request, create_draft_release, create_branch, delete_branch, fix_code
Pull requests read	pr_lookup, merged_pull_requests, list_pull_requests, list_review_comments, pull_request_diff, merge_pull_request, delete_branch
Pull requests read and write	comment_on_pull_request, edit_pull_request_comment, reply_to_review_comment, resolve_review_thread, review_pull_request, update_pull_request, request_reviewers, label_pull_request, close_pull_request, reopen_pull_request, update_pull_request_branch, fix_code
Issues read	list_issues, issue_lookup
Issues read and write	create_issue, comment_on_issue, update_issue, label_issue, assign_issue, close_issue, reopen_issue
Deployments read	recent_deployments, running_commit, ci_status, redeploy
Actions read	list_workflows, workflow_runs, workflow_jobs, job_log, ci_status, ci_runs, list_environments, pending_deployments
Actions read and write	rerun_workflow, rerun_job, run_workflow, cancel_workflow, redeploy
Deployments read and write	review_pending_deployment
Checks read	ref_checks
Commit statuses read and write	The Halon review check that a strict lesson sets on a pull request
Dependabot alerts read	dependabot_alerts, dependabot_alert
Dependabot alerts read and write	dismiss_dependabot_alert, reopen_dependabot_alert
Code scanning alerts read	code_scanning_alerts, code_scanning_alert
Secret scanning alerts read	secret_scanning_alerts, secret_scanning_alert
Secrets read	list_actions_secrets
Secrets read and write	set_actions_secret. Setting an environment’s secrets also needs Environments read and write

list_repositories, list_tags and library_source need no permission beyond the one every GitHub app has. Some capabilities show more when the app holds one more permission, and say which one when it does not:

Permission	What it adds
Checks read	The checks on a pull request’s head in pr_lookup
Commit statuses read	The commit statuses in pr_lookup and ref_checks
Dependabot alerts read	The advisories a Dependabot pull request fixes, in pr_lookup
Administration read	The branch protection settings in branch_protection

To give Halon everything, grant all of these on the app: Actions, Commit statuses, Contents, Dependabot alerts, Deployments, Environments, Issues, Pull requests and Secrets read and write, and Administration, Checks, Code scanning alerts and Secret scanning alerts read.

list_actions_secrets lists a repository’s or an environment’s GitHub Actions secrets by name and when each was last set. GitHub never gives a value back. set_actions_secret sets one without the value ever passing through Halon. Halon names the secret and you type the value in a secure field in the chat, or Halon passes across a value another connection created, such as a Northflank webhook address. See Entering a secret. Organization secrets are not covered.

A capability the app was not granted says so on the connection, such as Needs Actions read in the GitHub App. A note above the capabilities counts the switched-on ones and links to the app’s settings on GitHub. Halon is told too, and says what is missing if you ask it to use one. Once an owner of the GitHub account accepts the permission there, the capability works on its next call. You do not need to reconnect.

Changes made to the app on GitHub show on the connection.

Shown	What happened on GitHub	What to do
Removed on GitHub	The app was uninstalled from the account	Click Reconnect to install it again
Suspended on GitHub	An owner suspended the app	Unsuspend it on GitHub, and the connection works again
No repositories on GitHub	Every repository was taken away from the app	Choose repositories for it on GitHub

While any of these shows, its capabilities stop, Halon is told why, and live updates are off.

Grafana

Grafana Cloud connects by signing in, one stack at a time. Click Connect on Grafana, type your stack’s address under Stack address, such as mystack.grafana.net, and click Continue with Grafana. On Grafana’s screen, leave Write access and Query access off so Firefight can only read. Query access runs SQL that can change data.

When your stack has more than one Loki, Prometheus or Tempo data source, open the connection and choose which one holds the logs, metrics and traces Halon reads, under Logs data source, Metrics data source and Traces data source.

Grafana keeps a sign-in for 30 days, so sign in again when it ends, see Keeping a connection healthy.

For a Grafana you run yourself, choose Use a server you run, paste the address of the Grafana MCP server you run into Server address, and if the server asks for a token, put a service account token after Bearer in Access key (sent as the Authorization header).

Linear

Linear connects through Firefight’s own Linear app. Click Connect on Linear and then Continue with Linear, and a Linear admin approves the app on Linear’s screen. There are no keys to copy. Every tool Linear offers arrives on the connection.

The app works in Linear as Firefight rather than as whoever connected it, so issues and comments it makes show as Firefight and the connection keeps working when that person leaves. If your workspace has no other issue tracker, Linear becomes the one incident actions and follow-ups are kept in step with, and the message after connecting says what that still needs. See Issue tracking.

You can also ask Halon from inside Linear. Assign an issue to Firefight, or mention Firefight in a comment, and Halon answers in the issue, reading the issue and its comments first. A follow-up comment carries on the same conversation. Halon there acts as Firefight’s own Halon agent, so it reaches only what is granted to that agent under Firefight agents in Permissions, never what the person asking can do. When it wants to make a change you confirm, it lists the change in the issue with Confirm and Skip to pick, and only a member whose email matches the Linear account that picks counts. A change an approval rule holds runs as soon as someone approves it, and Halon says in the issue how it went. These conversations live only in Linear and are not listed in Firefight.

If you would rather use a token, choose Use a token instead.

Jira

Jira connects in one click to Atlassian’s server for reading issues and opening follow-up work. Its dialog also offers Connect for issue sync, with Connect the Jira app, which connects Firefight’s own Jira app as a connection named Jira issue sync so incident actions and follow-ups stay in step with issues, and sets up the webhook that sends changes back. Choose the tracker under Settings → Workspace once it is connected. See Issue tracking.

To connect with a token instead, use an API key of an Atlassian service account, pasted after Bearer, once an organization admin allows API tokens for Atlassian’s server. A service account is not a person, so it keeps working when someone leaves.

With credentials

Cloud providers, coding agents and a few others connect with an API token and whatever else the provider needs, such as a project or an organization. Each field says where to find its value. Azure, Factory, Opsgenie and Tinybird run in more than one place, so their form also asks for the Region your account is in. Firefight checks what you paste with the provider before saving, so a wrong token or project is named on the form.

What Halon can read and change is what the token’s role allows, so give it a role with the access you want and nothing more. GitLab can also connect through GitLab’s own MCP server. Choose Use an MCP server instead on its form.

AWS asks for an IAM user’s access key, its secret and the Regions your account runs in. The list has every commercial region, the two AWS GovCloud (US) regions and the two regions of AWS in China, Beijing and Ningxia. GovCloud and China accounts have keys of their own, so a connection reads regions from one of them, or from the commercial regions, and the form refuses a mix. To read a GovCloud or China account as well, connect it as another environment. Links in Halon’s answers open in that account’s own console, the GovCloud console for GovCloud and the China console for Beijing and Ningxia. To have Halon follow your releases, let the access key read CodePipeline, CodeDeploy, CloudFormation stacks and their events, App Runner and Elastic Beanstalk. To let it stop or roll back a release, also allow ecs:StopServiceDeployment, codepipeline:StopPipelineExecution, codepipeline:RollbackStage, codedeploy:StopDeployment and cloudformation:CancelUpdateStack. To let it reboot an EC2 instance or an RDS database, allow ec2:RebootInstances and rds:RebootDBInstance.

On Azure, Halon reads a container registry’s ACR Tasks runs with the Reader role. Reading a run’s log also needs Microsoft.ContainerRegistry/registries/runs/listLogSasUrl/action, which Reader does not hold. For instant updates, also give the app registration EventGrid EventSubscription Contributor on each subscription.

Cloudflare

Cloudflare connects to its whole API through one capability that changes things, beside two that only read its API reference and its documentation. Beside them, Firefight adds three changes of its own, which run a failed Pages deployment again, cancel a queued or running Workers build, and split a Worker’s traffic between two of its versions by percentage. Each is switched on, granted and approved by its own name, like any other tool, so you can allow one without allowing the general one. A connection made before they existed has them already, switched on. What Halon can do there is exactly what you grant on Cloudflare’s own screen. Grant read permissions to let Halon look into traffic, security events, DNS and cache. Add permissions such as editing firewall rules or purging the cache when you want it to block traffic or clear the cache during an incident.

For a Worker, Halon also reads its builds with their logs, and its newest versions beside its deployments, including any not deployed yet. Each Worker on the map opens its own page in the Cloudflare dashboard.

In a chat, Halon asks you to confirm every change it makes in Cloudflare. Cancelling a Workers build asks you as for any other change, since Cloudflare does not say who started a build. An investigation only reads, so a change it proposes is a step of its fix, which runs only when a person applies it. To have an admin approve each change too, add an approval rule.

PostgreSQL

PostgreSQL connects straight to your database. Paste its address into Connection address (connection URL), such as postgresql://readonly:password@db.example.com:5432/app, and click Connect.

Use a database user that can only read. Firefight also runs every query read-only and stops any query that runs longer than 10 seconds, so a user with more rights still cannot change anything through it. A query returns at most 200 rows.

The database must be reachable from the internet, since Firefight connects from its own servers. An address inside a private network is refused on the form. Connections are always encrypted, so an address with sslmode=disable or sslmode=allow is refused.

If your database needs certificates, choose Add certificates. Paste the CA certificate when the database’s certificate is signed by its own authority, such as your cloud provider’s, and paste a client certificate and its unencrypted key when the database asks the client to prove who it is. Certificates are stored encrypted with the address. Connecting again replaces them, so paste them again when you change the address.

Halon reads what has gone wrong in the database since its statistics were last reset, such as rolled back transactions, deadlocks and temporary files. When the pg_stat_statements extension is installed, it also lists the queries that took the most time, with how often each ran and its average time. Without the extension, Halon says so, and adding it is up to you. Give the user the pg_read_all_stats role to let Halon see the queries other users ran.

To connect another environment’s database, connect PostgreSQL again under the same name and choose that environment. Choosing an environment that is already connected replaces its address, which is how you change a password. Like tokens, connection addresses are stored encrypted and never shown again.

If you already run an MCP server for your database, or it cannot be reached from the internet, choose Use an MCP server instead and connect it with a server address and an access key as above. Back to connection address returns to the first form.

Northflank

Northflank connects with an API token and the projects it reads. Firefight checks both with Northflank before saving, so a wrong token or project is named on the form.

1. In Northflank, create an API token whose role can list and read the projects, their services, databases and jobs, and view observability. Add permission to read workflows, pipelines and their runs if you want Halon to follow your releases, to read secret groups if you want services linked to the databases their secret groups hold, to update services if you want Halon to apply fixes, and to read, create and delete notification integrations if you want the map to follow changes as they happen.
2. Click Connect on Northflank, paste the token into API token, and pick one or several projects under Projects, or All this token can read. See Choosing what a connection reads.
3. If your workspace has environments, pick the one these projects run. Connect again under the same name to add another environment’s projects.

Once connected, Halon can list the project’s services and databases, search their logs, read their metrics (CPU, memory, requests, 4xx and 5xx responses, network, open connections and disk), and see how each one is set up. That covers a service’s rollout, the repository and commit it runs, its health checks and ports, or a database’s status, storage, replicas and latest backups. It can also read deployments and who made them, containers and their restarts, builds and their logs, job runs with each run’s own logs and metrics, how a job is scheduled and set up, a database’s backups, and the runs of your workflows and release flows with each step’s outcome.

One capability, api_request, reaches the rest of Northflank’s API inside the project, such as restarting, scaling, pausing or rolling back a service. It and add_workflow_webhook, below, are the capabilities that can change things. Like every capability they arrive switched on, so switch them off if you do not want Halon to make changes in Northflank. A member needs the connection’s changes pack to use it, see Built-in packs. When the API has no call for what you asked, such as creating a pipeline, Halon says so and gives you the steps in Northflank’s dashboard instead. A change the token’s role cannot make is refused with the permission to add in Northflank.

add_workflow_webhook adds a webhook trigger to a Northflank workflow, so a CI job or another system can start it by calling an address. Like api_request it changes things, so a member needs the connection’s changes pack for it and approval rules apply, and the token’s role needs permission to update workflows. The address works like a password, so Halon never shows it. You reveal it from the card under Halon’s step, and Halon can set it as a GitHub Actions secret for you without it passing through the chat. The address takes the run’s details in its query string, such as release.sha and release.branch for a Git trigger called release, name and description for the run, and any other parameter as one of the workflow’s arguments. When you change a workflow through Halon, its existing webhook addresses stay the same.

Azure DevOps

Azure DevOps connects with a personal access token, your organization and the projects the connection reads.

1. In Azure DevOps, open User settings, then Personal access tokens, and make a token for your organization. Make it as a user set aside for Firefight where you can, so changes show under that name rather than a teammate’s and the connection keeps working when someone leaves.
2. Give the token Code, Build, Release and Project and Team (Read), and Environment (Read & manage), which is how Azure DevOps lets a token read what an environment received.
3. Click Connect on Azure DevOps and paste it into Personal access token.
4. Type your Organization, the part after dev.azure.com/ in its address.
5. Pick one or several Projects, or all the token can read, which also takes in a project added later. See Choosing what a connection reads.

To let Halon do more, give the token more:

To let Halon	Give the token
Run a pipeline, rerun its failed jobs, cancel a run or deploy an earlier deployment again	Build (Read & execute) in place of Build (Read)
Approve or reject an approval a run waits on	Pipeline Resources (Use), and make the token as a user who is one of that check’s approvers
Comment on a pull request	Code (Read & write)
Follow changes as they happen	Service Hooks (Read, query, & manage), on a token from a project administrator. See Live updates

Once connected, Halon reads your repositories, pull requests and code, your pipelines and their runs with each stage and job and its log, the approvals a run waits on, what each environment received and your classic release deployments. Ask it about a repository or a pipeline by name, such as “how did the last checkout-ci run go”, or ask it to rerun the failed jobs of a run, cancel one, answer an approval or roll back. Every change asks you first, and Halon reads what it can before it proposes one.

To roll back, Halon deploys an earlier deployment again. For a YAML pipeline it runs again the stage that made that deployment, in the run that made it. A classic release is deployed to its stage again. The deployment you name must have succeeded and its run must have finished, and any approvals and checks on the stage or environment still wait for a person.

CircleCI

CircleCI connects with a personal API token. In CircleCI, open User settings, then Personal API Tokens, and make a token as a dedicated user, such as Firefight, so changes do not show as a teammate’s and the connection keeps working when someone leaves. Click Connect on CircleCI and paste it into Personal API token. The token reaches every project in the organizations its user belongs to, and each one appears on the resource map as a pipeline, linked to the repository it builds when CircleCI says which.

Ask Halon how a project stands, for its recent runs, a failing job’s log and tests, or what it deployed to each environment, by the project’s name, such as gh/acme/web. When you allow it, Halon reruns a workflow in full or from its failed jobs, cancels a workflow, approves a job a workflow holds for a person, runs a project’s pipeline on a branch or a tag, or rolls a deployed component back. Each of these asks you first, and an approval cannot be taken back. A rollback runs the project’s rollback pipeline, so set one up in CircleCI first. What a project deployed comes from the deploy markers in its config.

To connect through CircleCI’s own MCP server instead, choose Use an MCP server instead on the form, then Continue with CircleCI. That connection has only the server’s own tools. It can read runs and rerun or cancel a workflow, but it cannot run a pipeline, approve a held job, read what was deployed, roll back or follow changes live. A CircleCI connection you made through the server before keeps working as it is.

Charts

When Halon reads metrics, you see them as charts under its answer in the dashboard chat, with a link that opens the live chart where the provider has one. In a Slack thread, each chart is posted after the answer as an image with its key numbers and the same link. If your Slack workspace has not yet approved Firefight to post files, the numbers and the link are posted without the image. A chart looks the same when you come back to the conversation later.

Choosing what an integration can do

Once connected, open the connection to see every capability the tool offers. All of them arrive switched on, the ones that read and the ones that change something, and so does a capability the tool adds later. Each one shows a line saying what it does. For a capability Firefight does not know yet, such as one a custom server offers, that line is the first sentence of the server’s own description.

Being switched on is not the same as anyone being allowed to use it. Every member can use the capabilities that read, unless an admin took that away. A capability that changes something needs a grant, usually the connection’s changes pack, and your approval rules still apply. Agents and service keys can use nothing until you grant it. Every call is recorded in Activity. Switch off anything you never want used, by anyone, admins included. See Permissions.

For long lists, use the controls above the capabilities.

Control	What it does
Reads only	Turns on every capability that only reads, and turns off every one that writes
Enable all	Turns on everything the tool offers, including capabilities that write
Disable all	Turns everything back off

Capabilities that change something in the connected tool are marked write. The header tells you how many are on, and how many of those write, so widening access is visible at a glance. A message confirms each switch and each of these controls.

Firefight knows which capabilities only read for each tool it lists. A capability a tool adds that Firefight does not know yet arrives marked write. Halon calls a read without asking you first, and approval rules never hold one, while every capability marked write asks before it runs.

Marking reads on a custom server

Firefight cannot know which of a custom server’s capabilities only read, so every capability of a custom server arrives marked write. If one only reads, such as a log search or a status check, click Mark as read under it and confirm. From then on it behaves like any other read:

• Halon calls it without asking first
• Approval rules never hold it
• Investigations can use it
• Members can use it without a grant

Mark a capability only if it never changes anything. Unmark as read puts it back, and Halon asks before each call again. Each change shows a confirmation and is recorded in Activity.

Tip

Reads only switches off everything that writes in one step, when you want a tool used for investigating and nothing else. You can always switch individual write capabilities back on afterwards.

Confluence pages in the handbook

Once Confluence is connected, Halon can search it for the runbook of a failing service and read it during an investigation. To keep a Confluence page in Halon’s handbook, open Handbook, click Import docs, choose your Confluence connection and paste the page’s link, such as https://acme.atlassian.net/wiki/spaces/ENG/pages/123456/Runbook. A Notion page works the same way with its link.

Environments

If your workspace has environments in the service catalog, a connection can hold separate credentials for each one, so production and development are reached with different access.

Connect the same integration again under the same name, choosing a different environment each time. You get one connection with a set of credentials per environment, one tool list, and the same capabilities. What changes is who is allowed to use it where, which you control in Permissions.

To change which environment an existing connection’s credentials answer for, open the connection and use the dropdown next to those credentials. A message confirms the environment it now answers for.

Choosing what a connection reads

Some providers ask which part of your account a connection reads. These are Northflank and Railway projects, Google Cloud projects, Azure subscriptions, Azure DevOps projects, Render and Bitbucket workspaces, and Vercel teams. One connection can read one of them, several, or every one its credentials can read. The steps below use projects, and the others work the same way.

On the connect form, paste the token first, then open Projects. Firefight asks the provider which projects that token can read and lists them. Pick one or several, or pick All this token can read, which also takes in a project created later, within the hour. If the provider does not list them for that token, type a project’s id in the search box and choose Add. Firefight still checks every project with the provider before it saves the connection.

For Railway, the Environment you enter is read in each project you pick, so use its name, such as production, when you pick more than one project. Halon can still look into the project’s other environments, pull request environments included, when you name one in a chat, such as “check the deploy in the PR environment for pull request 412”. It changes only the environment you entered, so to let Halon change another one, connect it as an environment of its own. The map shows only the environment you entered.

To change it later, open the connection, change Projects under its credentials and click Save. Firefight checks the token can read what you picked, reads the connection again straight away, and confirms with a message. A project you remove leaves the map then.

When a connection reads several projects:

• The map keeps each project’s resources apart, so a service called web in two projects is two services, each named with its project, such as web in Faylee.
• A capability such as a restart, a scale or a log search reaches only the project the resource lives in.
• When Halon or an agent calls the provider’s own tools, it names the project, or names a resource on the map and the project comes from it. A name that matches resources in more than one project is refused, with the projects to choose from.
• Confirmations, Halon’s steps, approval requests and Activity name the project a call reaches, such as Faylee (Northflank), project acme.
• Halon refuses a change, without asking you, when what it wrote names another project than the one the call reaches.
• A project the token can no longer read is shown on the map as not read, and what it held stays on the map until it can be read again.
• Firefight follows changes as they happen in every project the connection reads, and stops following a project you remove.

Google Cloud lists the projects your service account key can read under Projects, and Azure lists the subscriptions your app registration can read under Subscriptions, once you have entered the Directory (tenant ID), App registration (client ID) and Client secret. A Google Cloud project waiting to be deleted and an Azure subscription that is disabled are not listed. Give the key or the app registration the same roles on each project or subscription you pick.

Render and Bitbucket ask for Workspaces and Vercel for Teams. Render lists the team workspaces your API key can read. Vercel lists the teams your token can reach, including your Hobby account, and you can leave Teams empty to read the account the token itself was made for. Bitbucket lists your workspaces by their ids, which needs a token with the read:workspace:bitbucket scope. Without it, type each workspace’s id, the part after bitbucket.org/ in its repositories’ addresses. Azure DevOps asks for Projects and lists the projects your token can read in the organization, which needs Project and Team (Read).

Google Cloud and Azure changes are checked in each project or subscription on its own. If one cannot be read, the map says so for that one and keeps following changes in the others. For Render, if Firefight’s webhook would be the only or the last one a workspace can have, Firefight asks before turning live updates on and names each such workspace.

A connection made before this keeps reading the one project, workspace, team or subscription it was connected with, and works as it did.

Paths Halon may not change

Halon’s code changes can touch any file in your repositories by default, because every change arrives as a pull request for someone to review and merge. Each GitHub, GitLab, Bitbucket and Azure DevOps connection keeps its own list of paths Halon may not change, and the list starts empty.

To set it, open the connection under Configure → Integrations and find Code changes. Under Paths Halon may not change, write one path per line and click Save. A message confirms the new list. Only admins can change it.

You write	What it covers
.github/workflows/	Every file in that folder and the folders under it
infra/prod/**	Everything under infra/prod, at any depth
*.lock	Every file ending in .lock, in any folder
Dockerfile	Every file called Dockerfile, in any folder
/Dockerfile	Only the Dockerfile at the top of the repository
config/secrets.yml	That one file, from the top of the repository

A path with no / inside it matches a name in any folder, and one with a / inside it starts at the top of the repository. * stands for any part of a name, ** for any number of folders and ? for one character. A line Firefight cannot read the way you meant is refused with the reason, such as one that starts with !, uses [ ] or { }, or points outside the repository with ...

When a change Halon writes touches one of these paths, nothing is opened. Halon tells you which files, in which repository, and where the list is, such as “Halon may not change .github/workflows/release.yml in acme/api. An admin can change this under Integrations, GitHub, Code changes.”

You can also ask Halon in a chat, such as “stop Halon editing anything under infra/prod” or “let Halon change .github again”. Halon shows you the change to the list and applies it once you confirm. Only an admin can make it, and it is recorded in Activity.

A coding agent you hand code changes to, Devin, Cursor or Factory, opens its pull request itself, so Firefight cannot stop what it pushes. Firefight asks it in its instructions to leave the same paths alone, and checks the files its pull request changes once it opens. Firefight only checks or comments on a pull request in the repository it asked the agent to change, through a connection that holds that repository. Any other pull request the agent names gets the same warning in Firefight, with no comment. When one of them is on the list, Firefight comments on the pull request naming the paths and asking a person to review it before it is merged, and never closes it. The same warning leads Halon’s answer in the chat, and in a fix it is shown on the step, on the run page and in the fix’s checklist in Slack. When Firefight cannot read which files the pull request changes, it warns the same way, on the pull request too, and says why.

To comment on GitLab, Bitbucket and Azure DevOps pull requests, the connection’s token needs write access to them. Without it the warning still shows in Firefight and says the comment could not be posted.

Caution

A change to a CI workflow, such as a file under .github/workflows, .gitlab-ci.yml, bitbucket-pipelines.yml or azure-pipelines.yml, runs with your repository’s secrets. When a change Halon writes touches one, the pull request starts with “This changes a CI workflow, which runs with this repository’s secrets. Review it carefully.” and Halon says the same in the chat. Add those paths to the list if you never want Halon to change them.

Repository setup

Before Halon writes a code change or runs a repository’s tests, it sets the repository up the way your CI does. It starts the services your CI starts, sets the variables your CI sets and runs the commands your CI runs before the tests, such as loading the database schema.

Halon reads this from your CI the first time it works in a repository: .github/workflows on GitHub, .gitlab-ci.yml on GitLab, bitbucket-pipelines.yml on Bitbucket and azure-pipelines.yml at the top of the repository on Azure DevOps. It picks the job that starts the most services, or else the one that runs your tests. The test command itself is left out, since Halon runs the tests it needs. So is anything only your CI system can fill in, such as a secret, an expression or what an Azure DevOps pipeline takes from a template, and the password in a database address, which the sandbox does not need. Each repository’s setup lists what was left out and why.

The sandbox starts Postgres and Redis. Its Postgres has pgvector and the extensions that come with Postgres, such as pg_trgm, hstore, uuid-ossp and citext, so a repository whose CI uses a pgvector database runs its tests there. A service your CI starts that the sandbox cannot, such as Elasticsearch, is shown with a warning, and Halon prepares the repository without it. The same goes for a Postgres extension your CI’s database image or a setup command needs that the sandbox does not have, such as PostGIS. Neither stops a code change. Its pull request and Halon’s answer list what needs them under Could not run here with the reason, and your CI runs it.

To see or change it, open the connection under Configure → Integrations and find Repository setup. Only admins can change it, and a message confirms each change.

To	Do this
Set up a repository before Halon works in it	Click Set up a repository, type its name, such as acme/api, and click Read from CI
Set up a repository that has no CI	Click Set up a repository, type its name, click Set up by hand, add services, variables and commands, and click Save
Change a setup	Open its menu, choose Edit, change it and click Save
Read a setup from CI again	Open its menu and choose Read from CI again. When an admin changed it, Firefight asks first, since your changes are replaced
Clear a setup	Open its menu and choose Clear, then confirm. Halon reads it from CI again the next time it works in the repository

Variables are written one per line as NAME=value. A variable the sandbox sets itself, such as PATH, a variable written twice, a password in an address and anything that looks like a credential are refused with the reason. Firefight never keeps a credential in a repository’s setup.

What a repository installs, such as its gems and packages, is kept for your workspace, so the next change or test run in the same repository starts faster. It is installed again when a lockfile, a version file or the setup changes, and is never shared with another workspace.

A repository with no CI

A repository with no CI has no setup to read. Halon installs what its lockfiles and version files ask for, runs the checks it can, and still opens the pull request, with what it could not run under Could not run here. The pull request and Halon’s answer then say plainly that the repository has no CI, so nothing beyond the checks Firefight ran tested the change, and your review decides whether it is ready. You can set such a repository up by hand as above.

Several accounts of one provider

Connecting the same tool under a new name is a different thing. Use it when you have two separate accounts, such as two GitHub organizations or two Northflank teams. On a provider that is already connected, click Add connection. In the one-click dialog, choose Add a second account and give it a Connection name. On a credentials form, type a new name. Its capabilities and permissions stay entirely separate from the first.

Firefight shows the connection by its name and the tool’s, such as Faylee (Northflank), wherever a call through it is shown to you, such as Halon’s steps and confirmations, approval requests and Activity. Pick a name that says which account it is.

A few names are refused when you connect, with the reason shown.

• All is kept for asking every connection at once
• A name that would give one of its capabilities the same tool name as another connection’s capability, since AI agents see each capability as the connection’s name and the capability’s name joined together. If a capability added to the tool later would clash the same way, it cannot be switched on, and the connection says so

Keeping a connection healthy

Each set of credentials shows its own status.

Status	Meaning
Healthy	Firefight reached the tool and read its capability list
Failing	Firefight could not reach the tool, with the error shown on the connection
Not checked	Firefight has not contacted the tool yet

A connection you signed in to can see its sign-in end, when the tool stops accepting it, such as Grafana after 30 days. It then shows as failing, with an error saying the sign-in has ended. Open its details, choose Add connection and sign in again under the same name. Its capabilities and permissions stay as they were.

Refresh tools re-reads the capability list and rechecks health. Run it after the tool adds features you want, or when you are diagnosing a failure. A message says whether it worked, and when the tool could not be reached, the connection shows why.

If a capability disappears from the tool, it switches off and stops being available. Should it come back, the permissions you granted for it are still there, so you do not have to set them up again.

Turning an integration off

The toggle on an integration is a kill switch. Turning it off immediately removes its capabilities from everything, including Halon and agents connected over MCP, without losing your configuration. Turn it back on and everything returns. A message confirms either way.

Disconnect asks you to confirm, then removes the connection from your list and stops every capability it provided.

For GitHub, the confirmation also offers Also remove the Firefight app from the account on GitHub, ticked by default. Leave it ticked to uninstall the app from that account as you disconnect, which shows in Activity under your name. When another connection uses the same installation, in this workspace or another, the box is unticked and cannot be ticked, and the reason is shown under it. If you untick it, the app stays installed, and the confirmation that follows links to the app’s settings on GitHub so you can remove it there.

Caution

Disconnecting stops Firefight using the access, but apart from the GitHub app it does not revoke it at the other end. To cut access completely, also revoke Firefight in that tool’s own settings.