Your system, from context to components.
A C4 view of your codebase derived from the real dependency graph: Level 1 system context, Level 2 containers, Level 3 components. Framework-aware route-to-handler edges and execution-flow tracing across 15 languages. Nothing hand-drawn, nothing to keep in sync.
Architecture diagrams go stale the day they are drawn. The whiteboard photo, the Lucidchart that nobody updated, the README diagram that lies.
A diagram is only worth trusting if it matches what runs. repowise stops drawing the architecture by hand and derives it from the dependency graph instead, so the view is rebuilt with the code and stays true to what actually ships.
A view of the system that comes from the code.
Three C4 levels, framework-aware edges, and execution flows, all derived from the same graph that powers the rest of repowise.
System context, containers, and components
Three levels of C4, derived from package info and the dependency graph rather than hand-drawn. Containers come from manifest parsers with a top-directory fallback, components from sub-modules, and the external-system registry is built by the same manifest parsers that read your dependencies.
- Level 1 system context: your system and the external systems it talks to
- Level 2 containers: deployable parts from package info, with a top-directory fallback
- Level 3 components: sub-modules and the relations between them
- URL-synced views so you can share a link to an exact slice
Route-to-handler edges static parsing misses
Framework-aware resolvers connect an HTTP route to the code that actually handles it, so the graph reflects how requests really flow through your system, not just which file imports which.
- Django, FastAPI, Flask, Express, NestJS, Next.js App Router
- Spring Boot, Jakarta, Quarkus, Micronaut, ASP.NET MVC and Minimal API
- Gin, Echo, Chi, Go net/http, gRPC, Axum, Actix
- Rails, Laravel, and more, across the supported languages
The symbols that actually matter, surfaced
On top of the static dependency edges, repowise traces execution flow and ranks nodes by importance so the view stays legible at scale. PageRank and betweenness centrality surface the symbols most code paths run through instead of treating every node as equal.
- PageRank and betweenness centrality to rank and trace
- Execution-flow tracing over a three-tier call resolution pipeline
- A two-tier file plus symbol graph underneath every view
- Interactive dependency graph visualization scaling to 30K+ nodes
From source files to a living C4 view.
Parse
Tree-sitter ASTs across 15 languages build a two-tier file plus symbol graph. No code is sent anywhere.
Resolve
Three-tier call resolution plus framework-aware resolvers add route-to-handler edges other tools never see.
Rank
PageRank and betweenness centrality trace execution flow and surface the symbols that actually matter.
Derive
Containers, components, and external systems are derived into Level 1, 2, and 3 C4 views, rebuilt on every commit.
One graph, every way you read the system.
Level 1 system context
Your system and the external systems it depends on, registered by the manifest parsers that read your dependencies.
Level 2 containers
The runnable parts of the codebase, derived from package info with a top-directory fallback when there is none.
Level 3 components
The sub-modules inside a container and the aggregated relations between them, drilled in from the level above.
Interactive graph
The full dependency graph, laid out with ELK and rendered with React Flow, ranked and traced, scaling to 30K+ nodes.
Framework-aware edges
Route-to-handler links for Django, FastAPI, Express, NestJS, Spring Boot, ASP.NET, Gin, Axum, Rails, Laravel, and more.
Wired into the platform
Click from a container straight into the wiki, code health, and git risk for the files behind it.
Other tools ask you to draw the architecture and keep it current by hand. repowise derives the C4 view from the code itself, framework-aware edges and execution flows included, so it stays true to what actually ships.
Questions, answered
What are the C4 levels?
C4 is a layered way to read a system at increasing detail. repowise derives three of them straight from your graph: Level 1 system context (the system and the external systems it talks to), Level 2 containers (the deployable or runnable parts, derived from package info with a top-directory fallback), and Level 3 components (the sub-modules inside a container and the relations between them). You move between levels in the dashboard, with the view URL-synced so you can share a link to an exact slice.
Is the diagram kept up to date?
Yes. The view is not hand-drawn and it is not a snapshot you have to remember to refresh. It is derived from the dependency graph, which is rebuilt incrementally on every commit. When the code changes, the containers, components, and edges change with it, so the architecture you see is the architecture that actually ships.
How does it know my framework's routes?
repowise ships framework-aware resolvers that add route-to-handler edges static parsing alone would miss. That covers Django, FastAPI, Flask, Express, NestJS, Next.js App Router, Hono, Remix, SvelteKit, Astro, tRPC, Spring Boot, Jakarta, Quarkus, Micronaut, ASP.NET MVC and Minimal API, Gin, Echo, Chi, Go stdlib net/http, gRPC, Axum, Actix, Rails, Laravel, and more. The result is a graph that connects an HTTP route to the code that actually handles it.
How big a codebase can it handle?
The interactive dependency graph visualization scales to 30K+ nodes. It is laid out with ELK and rendered with React Flow, with PageRank and betweenness centrality used to rank and trace so the view stays legible even on large repositories rather than collapsing into a hairball.
Which languages does it support?
Tree-sitter ASTs across 15 languages, with full-tier depth for Python, TypeScript, JavaScript, Java, Kotlin, Go, Rust, C++, and C#, and good-tier support for C, Ruby, Swift, Scala, and PHP. Manifest and config formats including OpenAPI, Protobuf, GraphQL, Dockerfile, and Terraform are parsed for external systems and containers.
Can I see execution flows?
Yes. On top of the static dependency edges, repowise runs execution-flow tracing and uses PageRank and betweenness centrality to surface the symbols that actually matter, the ones most code paths run through, rather than treating every node as equally important. A three-tier call resolution pipeline and a two-tier file plus symbol graph back the trace.
Where does the architecture view live?
It lives in the repowise dashboard alongside the wiki, graph, code health, git intelligence, and decisions, so you can move from a Level 1 system context straight into the file-level documentation and risk for any container. You can explore it on live public repos or self-host it for private code.
Does it use an LLM to draw the diagram?
No. The C4 view is derived deterministically from the dependency graph, package info, and the external-system registry built by manifest parsers. There is no model in the layout path, so the same code always produces the same view and there are no token bills for rendering it.