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. Its sections include Accounts & servers, Environments, Code search (where your repositories define infrastructure) and Secrets. The live map of what is running, the Topology, is on the Jobs screen, described next.

Topology (on the Jobs screen)

The live map of your estate lives on the Jobs screen, next to the conversation that changes it. Use the Chat | Topology switch in a job's header, or on the New job screen:

• Topology puts the map where the plan and messages were. The message box stays at the bottom, so you can ask for a change and watch it happen on the map.
• The job's resources are marked live: blue while a step is working on them, green once that step is done, red if it failed. A folded group gets a blue outline when the job is working inside it.
• The map flies to the job's resources when you open a job. A banner at the bottom says what it is touching (Running · step 5 of 8 · Working on web-1), and Show flies back to them.
• A strip above the map shows the step the job is on and the crew's latest update. When the job needs your approval, the strip turns orange with a Review plan button that takes you back to the plan card.
• Chat shows the conversation exactly as before. SnapFlow remembers your choice between jobs.

The old /cloud?tab=topology link and the /infra command now open Jobs with Topology on. Everything below describes the map itself.

The Topology tab draws everything SnapFlow can see as one live blueprint, the way architecture diagram tools do. Beside it is the Overview panel, with three tabs:

• Overview: what you have selected (including its real ID, ready to copy), the estate health gauge, how the estate is spread across providers, and the critical issues.
• Issues: every issue with its suggested fix and a button to run it.
• Resources: the estate as a tree of plain names.

Hide the panel with ⇤ and bring it back with ⇥ Overview.

The toolbar.

• Provider tabs (All · AWS · GCP · GitHub · Servers, each with a count) show one cloud at a time or everything.
• Health | Cost switches between the health map (pictures, issues, internet exposure) and the spend map.
• Type filters by kind of resource (compute, databases, storage, containers and so on).
• Only issues keeps just what needs attention, plus whatever it sits in.
• Relationships turns the reference lines on or off. The internet lines always show in Health.
• Reset view puts all of this back to the default.

Group by. The coloured chips decide how the map is organised, in order: Provider ▸ Region ▸ Network, plus any tags you add.

• Each chip has the same colour as the groups it draws on the map: purple regions, green networks, and a colour of its own for each tag.
• The eye switches a level on or off. With Network on, instances sit inside their VPC. With it off, they sit directly in their region.
• + Tag groups by any tag your resources carry, for example env or team. Resources with the same value share a plate (env:prod), and untagged ones sit beside the tag plates.
• Tag chips can be dragged to reorder them and removed with ×.

Your grouping, tab and 2D/3D choice are remembered in this browser.

How to read the map. Each provider is a flatbed in its own colour: AWS orange, Google Cloud blue, GitHub purple, your own servers green, with the provider's cloud logo standing on it. Groups inside it are pale beds whose name sits on a dark tab along the front edge (N. VIRGINIA · US-EAST-1). Anything that holds other resources is a raised white slab with its contents standing on it: a VPC and its instances, a server and its containers, a container and the ports it listens on, a repository and its workflows. Every resource stands as a colour-coded isometric picture of what it is, so you can read the map without a legend:

• A blue server unit: a cloud instance (EC2, Compute Engine, Azure VM); a flatter indigo unit is one of your own servers
• A purple disc stack: a database (Postgres has its own blue block)
• A green object store: a bucket or storage account; a green drive unit is a disk
• A blue container: a container or container service; a cluster has its own unit
• A violet gear: a function or a service on a server
• A red padlock unit: a security group, firewall rule, role or key
• A teal octagon: a network, subnet or listening port; gateways, load balancers and DNS each have their own
• Shelves of boxes: a repository; a conveyor is a workflow

Each resource's name is written on the ground in front of its picture, with what it is underneath (web-1 · EC2 instance · t3.micro); a name in orange or red needs attention. Dashed lines run along the bed on the map's grid and show one resource referring to another, such as an instance using a security group. When the end of a line is inside a folded group, the line goes to that group instead.

What the internet can reach. An Internet globe stands just off the estate's edge. A line runs from it to every resource the internet can actually reach, and the ports that are open to the whole world sit where the line arrives (22, 443). SSH, remote desktop, database ports and "all ports" are red, and so is their line. This is drawn from facts discovery recorded, never guessed: an AWS instance with a public address plus the security-group rules that allow 0.0.0.0/0 or ::/0, an internet-facing load balancer, or a CDN. A Google Cloud instance with an external address is shown as reachable without ports, because its firewall rules aren't yet recorded with the instances they target.

Names you can read. The map never shows raw IDs. A resource is labelled with its Name tag or its own name. If it has neither, it gets its type plus a short tag (EC2 instance #7890). Hovering shows the name and one line, for example EC2 instance · t3.micro · Healthy. The real ID is in the side panel's Selected card and at the top of the detail sheet.

Status first. Anything that needs attention glows orange with a warning triangle on its picture; anything critical or down glows red. Stopped resources are greyed out. Zoomed out, each group folds into a chip showing its name, how many resources it holds and a health ring (N. Virginia · 25 resources). Problem resources inside a folded group stay lit, and when two chips would overlap the second shrinks to a count. Hover over a picture or chip to see what is wrong with it in a card: a health percentage for a group, or the issue's name for a single resource (web-sg · SSH open to the internet). Cards appear only while you point at something, so the map stays clean. In Cost, the pictures give way to plain blocks, shaded and raised by their estimated monthly list price, and hovering shows what each one costs.

Watching a job happen. With a job open in Topology, what it does shows up on the map as it happens:

• Create: a translucent picture of what it is making stands in the right place straight away, on a marching ring and labelled Being created…, in a region the map has never shown if needed (create an EC2 instance in us-west-2 brings up an OREGON · US-WEST-2 plate). When discovery finds the real resource, it drops into that spot, the map frames it, and the banner says Created ….
• Delete: what was removed greys out, sinks and fades away.
• Change: a resized instance, an edited rule or a new tag makes its picture glow a few times.

After every job that changes your infrastructure, SnapFlow re-scans straight away, and every enabled AWS region is read, not just your connection's home region. While a job is working, the map re-reads every few seconds.

Live. The map re-reads your estate every 15 seconds while it is open, and again when you come back to the tab. A server's status comes from its agent's heartbeat, so a box that goes quiet turns red within about a minute and a half, and a newly connected server appears straight away. The Overview panel shows a LIVE clock and names what changed ("+2 new · 1 status change"). Things only move when the estate or your grouping changes.

Getting around.

• Zoom and pan: scroll or pinch to zoom, and drag to pan.
• Open things: click a group, slab or chip to fly into it. Click a resource for its detail sheet, where its actions are. The selected resource gets a ring at its base and a name tag.
• Go back up: the breadcrumb under the search box (All › AWS › N. Virginia › prod-vpc) takes you back up, and so does Esc.
• Find: press / to jump to Find in map, which finds any resource, region, owner or tag group by name or ID.
• Buttons on the right: zoom, fit everything, and switch between 2D and 3D.
• Legend: the bottom-left box explains the colours, the pictures and the internet lines, and folds away.
• Highlight an issue: hovering an issue in the panel highlights the resources it affects.

Empty state: "Nothing on the map 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:

Connecting AWS first asks one question: how far may SnapFlow grow its own access? The setup is the same whichever you pick (read-only access plus a ceiling SnapFlow can never exceed), so you can change the answer any time under Cloud → AWS → Reconfigure without touching AWS.

What SnapFlow sets up in your AWS account

One workspace uses one IAM role in your account. SnapFlow never creates a role per job. Everything it uses has a fixed name, so you can audit it at a glance:

Before a job runs, SnapFlow checks that the role has the permissions the job needs. It checks every AWS service you can grant when connecting, so a missing permission shows up before anything starts, not halfway through.

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.

Infrastructure code (code-first changes)

Connect the GitHub repository that holds your Terraform or OpenTofu code, and SnapFlow keeps it the source of truth. Requires a connected GitHub integration. Fields: Owner, Repository, Base branch (default "main"), Working directory (optional), the tool (Terraform or OpenTofu) and After a pull request is merged — Our pipeline applies it (default) or SnapFlow applies it. When you save, SnapFlow tells you straight away whether it can read the repository.

With Code-first on (the default):

• What your code declares is changed in the code. Ask to change or delete a resource the repo declares — "set the visibility timeout of queue orders to 45 seconds" — and SnapFlow edits the block that owns it, runs plan with read-only cloud access, and opens a pull request with the plan in its description. Nothing changes in the cloud until a person merges it; during this step SnapFlow is refused every cloud change, whatever the agent tries.
• The job waits for the merge. The job shows "Waiting for the pull request to be merged" with a link. Merged: your pipeline applies it (or SnapFlow applies exactly the merged commit, through the same safety rules as any change), then SnapFlow verifies the live result — and only then charges the quote. Closed without merging: the job ends, nothing changes, nothing is charged.
• Everything else stays live. Resources the repo does not declare are changed directly, as before. Questions are still answered instantly — no pull request.
• Code follows live changes. When a live change touches something the code declares (an incident fix, for example), SnapFlow opens a follow-up pull request that brings the code in line, so your next apply doesn't undo the fix. Resources SnapFlow creates are adopted with real resource blocks, not just import blocks.
• If SnapFlow can't read the repo, a change job pauses and says exactly what to fix, rather than going around your code.

With Code-first off, SnapFlow changes the cloud and opens a pull request of import blocks for what it created. 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.