Skip to main content
Private beta: AI SRE is currently in private beta and available to invited accounts only. To join the whitelist test, contact the Flashduty sales team to request access; features and the UI may change during the beta.

​
Overview

An Environment is where AI SRE agents actually execute actions. Every tool call the agent makes — running commands, reading or writing files, executing Skills, connecting to MCP services — happens inside an Environment. AI SRE provides two types of Environments:

Self-hosted Environment (BYOC)

A long-running Runner process deployed on your own machine. It maintains a persistent connection to AI SRE and stands ready to receive tasks at any time. You have full control over which machine it runs on and which internal resources it can reach.

Cloud Sandbox

A temporary container managed by the system. No installation required — works out of the box. It pauses automatically when a session is idle and wakes up the next time you send a message. This is the default fallback when no Runner is online.
The selection logic is straightforward: when your account has an online self-hosted Runner, AI SRE uses it first; otherwise it falls back to the cloud sandbox. You can also pin a specific Runner or force the cloud sandbox directly from the chat input area.
Throughout this page, “Environment” and “Runner” refer to the same thing: the record you manage in the console is called an Environment, while the actual process running on your machine is called a Runner. One Environment record corresponds to one Runner process.

​
Why self-hosted (BYOC)?

The cloud sandbox is great for quick exploration and troubleshooting that requires no network access to your infrastructure. When your investigation needs to reach your real environment, a self-hosted Runner is where it truly pays off. BYOC (Bring Your Own Compute) puts execution back in your hands:
The Runner runs on your own machine, so command output, logs, and files produced by tool execution stay within your environment. Sensitive data never has to leave your network perimeter before the agent can read and analyze it.
The cloud sandbox can only reach a controlled set of public domains by default — it cannot access services behind your VPC, private network, or dedicated line. Deploy the Runner on a machine that has direct access to those targets, and the agent can query internal databases, call internal APIs, and log in to jump hosts directly — with less round-trip latency than going through the public internet.
You control the OS account, filesystem permissions, and outbound network policy of the machine running the Runner. Combined with the scope and edit permissions, you can restrict a Runner to be visible only to specific teams, satisfying least-privilege and audit requirements.
A self-hosted Environment is your own machine — AI SRE does not take over its outbound network controls. The “configure allowed domains per environment” proxy policy that applies to the cloud sandbox does not apply to BYOC, which is why the self-hosted Environment form provides no network access configuration. All outbound traffic is governed entirely by the network and firewall policies of your machine.

​
Connecting a Runner

Go to Environments in the AI SRE left sidebar to create and connect a self-hosted Runner. The process has two steps: creating the record in the console to get a Token, then installing and starting the Runner on the target machine.
1

Create an Environment record

Click Create Environment in the top-right corner and fill in the form:
FieldTypeRequiredDescription
NameStringYesA unique name identifying this Environment; must be unique within the account; max 128 characters
ScopeAccount / TeamYesAccount scope is visible to all members in the account; team scope is visible and editable only by members of that team (see Scope below)
TagsString listNoTags used for task routing, comma-separated, e.g. linux, docker, gpu
After the record is created, an onboarding guide pops up containing the connection credential Token and a one-click install command for this Environment.
2

Get the Token (connection credential)

The Token is the sole credential a Runner uses to connect to AI SRE. Keep it safe and do not share it. It is injected into the Runner process together with the install command.
The Token grants execution capability to a Runner — if it leaks, someone else can impersonate that Environment. If you suspect a leak, delete the Environment from the list and recreate it. You can always view the Token again by clicking the Token button (key icon) on the list row.
3

Install and start on the target machine

The onboarding guide provides two installation methods. The TOKEN and URL values in each command are already filled in with the real values for this Environment:
Run a single command on the target machine as root / sudo. The script installs the binary and registers it as a persistent systemd service:
curl -fsSL https://static.flashcat.cloud/flashduty-runner/install.sh | sudo TOKEN=<your-token> URL=<connect-url> bash
The same install command works for both fresh installs and upgrades — if the latest version is already installed, it skips automatically.
The connect-url is the address the Runner dials into AI SRE (typically wss://api.flashcat.cloud/safari/environment/ws). It is injected by the deployment configuration — you do not need to fill it in manually. The onboarding guide already shows a complete, ready-to-copy command.
4

Verify online status

Once the Runner starts and connects successfully, it continuously sends heartbeats to AI SRE. Go back to the Environments list — the status of the corresponding row will change from Pending (never connected) to Online:
StatusMeaning
PendingThe record has been created, but the Runner has never connected. The list shows a “View onboarding guide” entry.
OnlineThe Runner is currently connected with a healthy heartbeat and ready to accept tasks.
OfflineThe Runner connected at some point in the past, but its heartbeat has since been lost.
Once online, the list also backfills the machine’s machine info (OS / architecture / hostname), the Runner version, and the last heartbeat time (“just now”, “N minutes ago”, “N hours ago”, etc.). When a newer version is available, an “Upgrade available” badge appears in the version column — clicking it reopens the onboarding guide so you can run the same command to upgrade.
Upgrades and uninstalls are also covered in the same onboarding guide: rerunning the install command on an already-installed Runner upgrades it. Two uninstall commands are provided — --uninstall removes the service while preserving config, and --purge removes everything including config and data.

​
Selecting an environment in a session

A persistent environment selector (environment chip) sits at the bottom of the chat input area and lets you specify which Environment the session runs in. Clicking it expands three categories of options:
OptionMeaning
AutoAI SRE automatically picks the best available environment: uses a Runner if one is online in the account, otherwise falls back to the cloud sandbox. This is the default for new sessions.
Cloud Sandbox · DefaultForces the system-managed cloud sandbox, ignoring any self-hosted Runners.
Self-hosted EnvironmentLists all Runners visible in your account. Offline / never-connected Runners appear grayed out and are not selectable — you can see they exist, but you cannot select a Runner that is currently offline.
The bottom of the selector also provides an “Add self-hosted Environment” entry that takes you directly to the Environments page to create a new Runner.
The environment selection stays with the session and is locked in once per session: the Environment determined when the session sends its first message is recorded, and all subsequent turns in that session continue to use it. Changing the selector afterward does not affect an already-started session. To use a different Environment, start a new session.
When you open a historical session, the selector shows the Environment that was locked in for that session along with its current status, in read-only mode. If the originally bound Runner is now offline or has been deleted, the chip displays a red dot labeled “Offline / Deleted” — clicking it expands the reason and provides a link to go to Environments. In this case the session cannot continue sending messages; you need to reconnect the Runner, or start a new session and switch to the cloud sandbox.

​
Scope

Like other resources (Skills, Knowledge Packs, MCP, Agents), each Environment has an account-level and a team-level scope:
ScopeVisibility
AccountVisible to all members in the account
TeamVisible and editable only by members of that team
In the “Scope” column of the Environments list, account scope is displayed as an “Account” chip, and team scope shows the corresponding team name. The ScopeBar above the list lets you filter by account or team. Edit permissions follow the unified rule:
  1. Account owner or account admin → can edit any Environment.
  2. Team member → can edit team-scoped Environments belonging to their team.
  3. There is no “creator extra permission” — you don’t have to be the creator to edit under the rules above.
How sessions pick a Runner (runtime visibility):
Scope is a label for editing and ownership, while the account is the sole security boundary at runtime. When a session needs to fall back or auto-select a Runner, the system picks from all online BYOC Runners in the account by matching tags; auto-selection does not hard-filter by team. Therefore, assigning a team-level scope to a Runner primarily constrains who can see and edit it in the console — not which sessions can use its compute.
If a session is bound to a specific team (for example, launched from a war room incident or explicitly assigned a team in the UI), that team’s Skills, MCP, and Knowledge are prioritized for the session’s toolset. Compute for the Environment is still bounded by the account.

​
Troubleshooting

When troubleshooting Runner issues, start with the Status and Last heartbeat columns in the Environments list — these fields directly reflect whether AI SRE currently recognizes the Runner.
Offline status means the Runner connected at some point, but AI SRE has not received a heartbeat from it for approximately 90 seconds and has marked it as disconnected. Common causes and remediation:
  • Process has exited: Log in to the target machine and check whether the Runner process or systemd service is running (systemctl status flashduty-runner). A crash or OOM kill will interrupt the heartbeat.
  • Machine or network interruption: A shutdown, sleep, network outage, or outbound firewall rule blocking traffic to AI SRE will prevent heartbeats from reaching the server.
  • How to recover: Simply restart the Runner and keep it running — it will reconnect automatically and resume sending heartbeats. The list status will return to “Online” after the next heartbeat.
Pending status means this Environment record has never successfully connected since it was created. Check each of the following:
  • Did the install command complete successfully? Confirm that curl ... | sudo TOKEN=... URL=... bash ran to completion without errors and that the binary is in place.
  • Is the Token correct? The TOKEN used by the Runner must be the Token for this specific Environment. Using a Token copied from another Environment or an old Token will cause authentication failure and prevent the connection from being established. Click the Token button on the list row to retrieve and verify it.
  • Is the connection URL reachable? The URL the Runner dials must be reachable from the target machine. First verify connectivity to that address from the machine itself before investigating further up the stack.
Session execution depends on an online Environment. When the selector is pinned to a specific Runner that is not online, AI SRE does not silently reassign the session elsewhere (sessions are locked in once) — it blocks immediately and reports that the Environment is unavailable. How to handle this:
  • Confirm that the selected Runner shows Online in the Environments list. If it is offline or pending, restore it using the steps above.
  • Temporary workaround: change the selector to Auto or Cloud Sandbox to route through the cloud fallback. Note that Environment binding is one-time — existing sessions already locked to an offline Runner cannot be reassigned. You need to start a new session and switch from there.
  • If the Runner shows Online but execution still times out, the problem is most likely between the Runner’s machine and the target resource (database, internal API, etc.), not between the Runner and AI SRE — investigate network and permissions on the target resource side.
The fastest way to determine “where the problem is”: look at the status first. Offline / Pending means there is an issue between the Runner and AI SRE (check heartbeat, process, outbound connectivity). Online but execution fails means there is an issue between the Runner and the resource being investigated (check the target resource’s network and permissions).

Sandbox

The default fallback execution environment when no Runner is online — managed, temporary, zero-install.

Console

View the Environment, team, and resources invoked by the agent that are bound to a session.

MCP (External Tools)

MCP connections are established per Environment at agent runtime.

Skills

Skills execute in the selected Environment — learn how to upload and enable a Skill.