Infrastructure & Targets

Overview

Infrastructure & Targets (route /infra) is the single place to see everything about the systems SnapFlow manages: a visual map of what's actually out there, which providers are connected, the deploy "boundaries" (environments) and how much autonomy each grants, and the credential vault for services SnapFlow installs on your behalf. Four tabs: Topology, Connections, Boundaries, Secrets.

Topology

Two stacked panels. First, an Infrastructure Overview band (once you have any resources): a colored state banner — Healthy Needs attention Critical — a numeric score, and count tiles for resources, repos, workflows, environments, and connected clouds. Below that, an issues list: each row has a severity tag, title, description, a suggested fix, and — where SnapFlow can act on it directly — a button that either navigates you to the fix or dispatches the fix as a new mission.

Second, the Infra Mind-Map — an interactive, deliberately static (non-drifting) diagram: "Your Infrastructure" at the root, branching into provider clusters (AWS, GCP, Azure, Kubernetes, DigitalOcean, GitHub, Servers), then services, then individual resources. A toolbar lets you search resources, filter by provider, toggle "⚠️ Issues only", and "↻ Rescan" everything connected. Click any node to open its detail panel. Empty state: "No infrastructure discovered yet" with a "Run discovery" button.

The node detail panel

Click any node to slide open its property page. The panel is deep-linkable — the URL gains ?inspect=infra:<resource id>, so you can share a link straight to one resource, and the browser back button closes it.

It shows everything discovery captured about that resource, grouped so a long list stays readable: Security first (encryption, versioning, public-access settings, permissions), then Network, Configuration, Timestamps, and anything else. Click any value to copy it. Below that: relationships (what it belongs to, what belongs to it), any issues affecting it, and its tags.

Acting on a resource

Each node offers the operations you would perform on it in your provider's own console — start, stop, resize and tag an instance; block public access or enable versioning on a bucket; restrict a firewall rule; restart a container or service; run, enable or disable a workflow. A repository additionally offers "Deploy to cloud…": pick AWS, GCP, Azure or DigitalOcean and SnapFlow works out how the repo builds, provisions what it needs there, deploys it, and verifies the result responds.

Destructive actions — terminating an instance, emptying or deleting a bucket, deleting a role, network or environment — are separated into their own Danger zone block at the bottom of the panel and marked Destructive. Before one can be dispatched you must type the resource's name to confirm. That is on top of, never instead of, the normal approval gate: a delete is always treated as critical, so it stops for a human decision in every permission mode.

Connections

Connect and manage every cloud and CI/CD integration — AWS, GCP, Azure, Kubernetes, GitHub, DigitalOcean, and locally-enrolled servers.

Connecting GitHub

Clicking Connect first shows a permissions preview modal, then either Proceed (installs SnapFlow's shared GitHub App) or Create your own app (choose specific permission scopes and create a dedicated app). Once connected, a panel shows repository access scope — No repositories All repositories Selected repositories — a "Manage on GitHub ↗" link, granted permission scopes, and a "Sync permissions" button.

Connecting AWS, GCP, or Azure

A chooser modal offers two paths:

AWS specifically adds a "What should SnapFlow be able to do?" permission-scope picker — a toggle list of service categories (compute, storage, database, etc). Read-only access is always included; anything you check additionally grants provisioning/change rights in that area. Reconnecting an already-linked AWS account updates the existing role in place rather than creating a new one.

Kubernetes diagnostics

Once connected, click "Open diagnostics" for a modal with four modes — Overview, Rollout, Traffic, RBAC — fields for namespace/deployment/service/service-account, and a Run button that returns findings, a risk level (low/medium/high), and recommended next steps.

Other providers & servers

Providers without a dedicated flow use a generic credential form (text/password/textarea fields), saved either directly or as a reference to an existing environment variable or Vault path. Locally-enrolled/on-prem servers get their own section near the top of the page. Anything without connect support yet appears, dimmed, under "Coming soon."

At the bottom, a collapsible Agent readiness strip shows how many of the fleet's capabilities are fully operational vs. blocked given your current connections — expand it to see, per capability, which providers back it and, if blocked, which one it's still waiting on.

Boundaries

Environments define how much autonomy agents get in a given part of your infrastructure — every environment decides its own approval policy, and a production environment always requires approval for something.

Click "+ New environment":

Each environment in the list shows its policy as a status chip (Auto Gate mutations Gate all), a "prod" tag if production, a "default" tag on the one un-deletable default environment, and its provider/policy/OIDC role/auto-revert details.

"Change-as-PR"

When configured, a mission that provisions resources also opens a pull request in the repo you specify, with Terraform import blocks — so every change is a reviewable artifact your own team owns, not just something SnapFlow did quietly. Requires a connected GitHub integration. Fields: Owner, Repository, Base branch (default "main"), Path prefix (optional). Buttons: Connect repo / Update repo, and Disconnect once set up.

Secrets

Agents reference these secrets by name — the values are injected into the command at run time and never appear in a prompt, a task payload, or the flight log.

Service setup (recommended)

Pick your install preferences for a catalog of installable services; SnapFlow generates the required passwords itself, stores them encrypted, and injects them when the install runs — nobody types them and no model ever sees them. Click Configure on a service, fill in its settings, review the box listing exactly which credential slots will be generated vs. already present, then Save & generate credentials.

Bring your own credential

For values SnapFlow can't generate itself — an existing service account, a license key:

Every stored credential shows a masked preview, a "Generated" or "Host-scoped" tag, when it was last used (or "never used"), and a Delete button. This entire tab is founder-only.