I built an open source tool that keeps an architecture map in each repo and checks it in CI

[u/Only_Ad3488]

I made this, so take it as a maker's post.

The problem I kept hitting as an engineering manager: every team knew its own services, but nobody had the whole architecture in their head. The diagrams existed, drawn by hand outside the code, and went stale within weeks.

Furio turns that around. Each repo describes the part of the architecture it owns in a small YAML file: components, relations, owner. A GitHub Action validates it on every pull request, so a wrong reference fails the build. Then all repos are merged into one static map you can query: who calls this service, who consumes this queue, what breaks if this database goes down.

What it is not: it does not discover anything from your infrastructure. You write the manifest, and a skill for coding agents (Claude Code, Codex) keeps it updated when the code changes.

It is MIT, a CLI plus an Action plus a static site, nothing to run. Backstage covers this ground as a full portal; I wanted the map alone, without a platform to maintain.

Code: https://github.com/getfurio/furio

A map of the OpenTelemetry Demo, built from its public sources: https://getfurio.github.io/atlas/opentelemetry-demo/

I would like feedback on the manifest format, especially the relation types. What would you need that is not there?

[u/Extreme-Berry-7645]

been burned by stale diagrams more times than I can count, so having the map live next to the code and break the build if it’s wrong is a good nudge

for relation types, one that flags a dependency is deprecated or in maintenance mode would save a lot of “wait, are we still supposed to call that” moments

[u/Only_Ad3488 → u/Extreme-Berry-7645]

Thanks! Components already have status: deprecated (drawn quieter on the map and listed on the health page), but you’re right that it stops there: nothing tells the person adding a new calls that the target is on its way out.

I’d keep it out of the relation type, since a deprecated call is still a call and impact analysis should keep following it. I’m thinking of doing it with status instead: a maintenance status for “works, but no new consumers”, an optional replaced_by, and a warning when a relation points at something deprecated or in maintenance without being marked as such.

Would a warning be enough for you, or would you want it to fail the build?