How cleap compares
Plenty of tools show you part of a system. Most of them are good at what they do. Here is what each is actually for, and the three things cleap does differently - stated as mechanisms you can check rather than ticks in a grid we drew ourselves.
1. The short answer
Nothing else is derived from the code, kept in sync automatically, spans code and databases and services together, and is legible to someone who cannot read code.
Each of those exists somewhere. A dependency graph is derived and automatic but for engineers. A service catalogue spans your services and cloud resources, but what each one is and who owns it is still written by a person. A C4 diagram is legible but authored once. Tracing shows real behaviour but only of what ran.
The combination is the product, and combinations are harder to copy than features. We would rather say that plainly than claim the underlying technique is proprietary, because it is not.
2. A catalogue drifts. A derived map cannot.
If keeping it accurate is someone's job, it will be wrong by Thursday.
Modern catalogues are better at this than they were. They discover repositories and cloud resources for you, and some now draft descriptions automatically. What no discovery pass can produce is the part that carries the meaning: what this service is for, who owns it, what depends on it and why. That is written by a person, and anything written by a person decays the moment attention moves elsewhere.
That is not a criticism of catalogue tools. It is the failure mode they all share, and the reason a catalogue that started complete rarely stays that way.
cleap has no maintenance step. A push triggers a re-parse, and the map is whatever the code currently says. Nobody has to remember to update it, which means nobody can forget.
3. A diagram is drawn once. A map has geography.
Positions here are computed and stored, so a thing is where it was yesterday.
Most generated diagrams re-lay out on every render, so the same system looks different each time you open it. That is fine for a picture and fatal for a map: recognising where something sits is most of what makes a map useful, and you cannot recognise a place that moves.
cleap computes layout once, server-side, seeded from the previous run, and stores the coordinates. A node nudges when the code changes; it does not reshuffle. That is also what makes a link to a location work, and a screenshot still true next month.
Rather than leave that as our own claim about our own product, it is written up as the Stable Map Spec - five properties with conformance tests anyone can run against any tool, including this one. That page also records where cleap fails them.
4. Most of these are built for engineers
cleap is the one your operations lead is expected to open.
Dependency graphs and trace diagrams are precise and dense, and assume a reader who already knows the vocabulary. That assumption is reasonable for their audience and it excludes most of a company.
cleap labels things in plain language, zooms continuously from the whole product to a single function, and puts the database and the third-party services on the same canvas. The test it is built against is whether someone who cannot read code can answer a question without interrupting an engineer.
5. Side by side
Pick the one you were actually considering.
cleap versus Service catalogues
Backstage, Port, Cortex, OpsLevel
| Question | cleap | Service catalogues |
|---|---|---|
| How does it stay current? | Re-derived on every push | Discovered, then described by hand |
| Who has to maintain it? | Nobody | Whoever owns each entry |
| Can a non-engineer read it? | Yes. That is the design target | Partly, if entries are well written |
| Code, database and services together? | One canvas | Services and resources, not code |
| Is a thing in the same place tomorrow? | Yes, coordinates are stored | It is a list, not a space |
| Does it show what actually ran? | No. Structure, not traffic | No |
| Ownership, on-call, service tier? | No | Yes. This is the whole point |
| Can you design something not built yet? | No. It reads what exists | No |
| What does it need before it works? | A connected repository | Integrations, plus a descriptor per repo |
Service catalogues wins one row. Choose a catalogue when the thing you need is a system of record for ownership, on-call and service tiers. Those facts live outside the code, so no amount of parsing will find them.
Not in the list: CodeSee. It was the closest predecessor - zoomable, GitHub-connected codebase maps. It wound down in early 2024 and GitKraken acquired the technology that May, folding it into their platform, so it is no longer something you can choose on its own. It proved people want this, and the gap it left is most of why cleap exists.
6. Where cleap is the wrong choice
Four cases where one of the tools above is simply the better answer.
You need to know what actually ran. cleap reads structure, not traffic. For real request paths, latency and production behaviour, use a tracing tool. The two answer different questions and sit happily side by side.
You need a system of record for ownership. Who is on call, which team owns a service, what its tier is. That is a catalogue, and a catalogue is the right tool for facts that live outside the code.
You are designing something that does not exist yet. cleap can only show you what is written. For a system still being argued about on a whiteboard, a C4 diagram is the right instrument.
Your language is not supported yet. cleap reads TypeScript, JavaScript, Python, Go, Ruby, PHP, Swift, Kotlin, Java and Rust today, and a repository in a language it does not read maps to nothing at all rather than to something partial. Will it work on my repo answers this properly, including what you get without framework support.