Your app, with the lid off

You deploy an app and you get a link. Behind that link there is more going on than the link lets on. Something decides where a visitor's request goes. Something runs your code. Maybe there is a database. And a few things you never set up, because Percher runs them for you.

Most hosts keep that machinery out of sight. We did too. This week the per-app dashboard grew a new tab, Topology, that draws the whole thing as a live map. You do not need to read all of it. But when something looks off, or you are just curious, the map is there, and every box on it tells you what it is.

The parts you set up

The top of the map is the stuff you wired up, directly or through your assistant. The container your code runs in. The router that sends traffic to it and handles HTTPS. A custom domain, if you added one. PocketBase and its disk, if your app stores data. A webhook that redeploys on every push.

Each card carries a small status dot and a small "i" you can click. The dot is the live state. The "i" gives you one plain sentence about what the thing is and a link to the docs, so the map works whether or not you know what a route table is.

The parts we run for you

Below that is a band labelled "Managed by Percher." These exist for every app the moment it first deploys, and you never configured any of them:

• Deploy history. Every version you ship becomes a commit in a private per-app Forgejo repository. That history is what rollback reads from when you want yesterday's build back.
• Metrics. We sample your container's CPU and memory continuously, which is where the graphs on the Resources tab come from. The platform also exposes Prometheus metrics for ops.
• Security scan. Every image you deploy is scanned for known vulnerabilities with Grype and Trivy.
• Backups. Your data is copied off-site every night.

Naming the tools is deliberate. If you are technical, you can see exactly what is doing the work and go read about it. If you are not, the one-sentence tip is all you need.

Green means we checked, not we hope

The part I care about most is what a green dot means. We decided early that a status should never read healthy unless we can actually prove it.

The security card is the clearest case. A clean scan writes no findings, so "zero findings" on its own could mean the image was scanned and came back clean, or it could mean the scan never ran. Those are very different states to show someone. So we record a scan timestamp against the exact deploy that is live. If the scanner failed open on your last deploy, the card says the image is not verified yet, rather than going green on the strength of an old, unrelated finding.

Backups work the same way. The card only goes green if your app shows up in a recent backup, and we judge "recent" by when the backup actually ran, not by when its index file was last written. A backfilled index from last month should not make a month-old backup look fresh.

Metrics, likewise, are green only when there is a recent sample, not merely a successful deploy. An app that deployed but never produced a single measurement is a real gap, and the card shows it as one.

None of this is hard. It is just the difference between a dashboard you can trust and a dashboard that is green by default. The second kind trains you to stop looking, which defeats the point of having it.

Your assistant reads the same map

The map is also an MCP tool, percher_app_topology. Ask your assistant whether anything is wrong with your app and it can pull the same node graph you see, with the same verified signals, and reason about it. That is the same bet the rest of Percher makes: the platform should be legible to the thing acting on your behalf, not only to a person clicking around a dashboard.

Open any app and look for the Topology tab. Tap a card to jump to it, or tap the "i" to find out what it is. The lid comes off, and nothing underneath turns out to be scary.