Stacktower draws your dependency graph as a tower of blocks

The idea, borrowed from an XKCD comic

Stacktower renders dependency graphs as physical towers where blocks rest on what they depend on, and the README is explicit about the source of the idea: it is inspired by XKCD #2347. Your application sits at the top, supported by libraries below, all the way down to that one critical package maintained by some dude in Nebraska. The visualisation is not an abstract graph drawing but a stacked physical metaphor, which is the point. A directed dependency graph with a thousand nodes is unreadable, while a tower conveys the same information as weight and height. The tool is a Go program, the licence is Apache-2.0, the default branch is main, and the homepage for the hosted service is app.stacktower.io. The releases are frequent and small, v1.6.4 on 2026-06-25, v1.6.3 the same day and v1.6.2 on 2026-05-13, with the last push to the repository on 2026-06-25. The repository topics are dependencies, golang and graphs.

Installing it, and the one thing the source build leaves out

The recommended route is Homebrew, and the reason is not convenience for its own sake.

brew tap stacktower-io/homebrew-tap
brew install --cask stacktower

The README says the Homebrew install includes everything out of the box, with GitHub authentication, private repo access and all CLI features working without extra configuration. Building from source, or using go install, does not embed the GitHub App credentials needed for stacktower github login, stacktower github install and stacktower parse github. Those commands will fail unless you manually set STACKTOWER_GITHUB_APP_CLIENT_ID and STACKTOWER_GITHUB_APP_SLUG, and the README states that all other commands, parse, render, resolve and the rest, work fine without them. The source install path is a go install of the cmd package.

go install github.com/stacktower-io/stacktower/cmd/stacktower@latest

Or you clone and build.

git clone https://github.com/stacktower-io/stacktower.git
cd stacktower
make build

The parse-then-render loop

The quick start shows three ways to produce a diagram, and they differ only in where the parse step happens. You can render a bundled example, where the XKCD-style tower is the default output.

stacktower render examples/real/flask.json -o flask.svg

You can parse a package from a registry and then render it.

stacktower parse python fastapi -o fastapi.json
stacktower render fastapi.json -o fastapi.svg

Or you can pipe one into the other.

stacktower parse python flask | stacktower render - -o flask.svg

The pipeline is deliberately two-stage, which is what lets the same parse output feed a local SVG or the hosted service. The CLI generates static SVGs locally, and Stacktower Cloud adds interactive towers, dependency history tracking, automated PR diffs through a GitHub Action, AI-powered health grading and team dashboards, all from the same parse output. That is a useful division: the expensive part, resolving and enriching the graph, happens once and is portable.

Supported languages and the resolution options

The parse command takes a language and a package, or a manifest file with the language auto-detected from the filename, or github with an owner and repository. The supported languages are python, rust, javascript, ruby, php, java and go. Each maps to its ecosystem registry, so the same shape of command reaches PyPI, crates.io, npm, RubyGems, Packagist, Maven Central and the Go Module Proxy. Version pinning is done with package@version, and without it the latest version is resolved, with scoped packages working for npm. The options table is where the real constraints live. The output flag writes to a file, and when it is omitted a TTY shows a summary and tree while piped stdout emits JSON. The max-depth option defaults to 10 with a maximum of 100, and max-nodes defaults to 5000 with a maximum of 50000, so a large project is bounded by default. The workers option sets concurrent fetch workers at 20 by default, and the dependency-scope option is prod_only by default, with all including dev dependencies. There are also options for including prerelease versions, for a target runtime version used in marker evaluation, for disabling the cache, and for security scanning.

Enrichment: GitHub metadata, contributors and the vulnerability scan

The enrichment options are what turn a dependency list into a picture with a story. The --enrich flag adds GitHub metadata, stars and maintainers, and it is on by default. The --contributors flag fetches GitHub contributors for the Nebraska rankings, which the README notes means slower API calls. The --security-scan flag does a best-effort scan for known vulnerabilities via OSV.dev. That last one deserves a caveat that the README's own wording supplies: it is best-effort, so it is a signal for triage rather than a verdict. The combination of contributors, maintainers and stars is what makes the tower narrative land, because it identifies which blocks are held up by a single person in one place. The vulnerability scan sits alongside that, so a diagram can show both the structural risk of a dependency and its known advisories.

Where Stacktower is the wrong tool

Three limits. The first is that the output is a diagram, not a lockfile. The resolution is bounded by max-depth and max-nodes, with 5000 nodes as the default ceiling, so on a large monorepo the picture is a truncated view, and the truncation is not something the diagram can tell you about at a glance. If you need the exact, complete set of what a project resolves to, a package manager's own lockfile is the authority and this tool is not a substitute. The second is the dependency on the network for the enrichment features. Fetching stars, maintainers and contributors per package means many API calls, and the README itself flags that the contributors option is slower, so on a cold cache over a large graph the parse step is slow and rate-limit sensitive. The third is that the GitHub integration is asymmetric between install methods, with the Homebrew cask carrying the GitHub App credentials that the source build lacks, which means the same command behaves differently depending on how you installed the tool. For a one-off illustration, the hosted app at app.stacktower.io does the same job with none of that setup, and for a CI pipeline the GitHub Action is the path that avoids the whole problem.

Editorial conclusion

Adopt Stacktower if you want a visual answer to what a package actually pulls in, and you are comfortable with the resolution limits it imposes. Skip it if you need a precise, reproducible dependency list, because the diagram is a bounded snapshot rather than an authoritative lockfile. Before you rely on it, check the --max-nodes and --max-depth limits against your project size, and note that the GitHub commands only work with the Homebrew build.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. stacktower-io/stacktower on GitHub