Generate from source

Generate an architecture diagram from a Django project.

Django's conventions are strong enough that most of the architecture is declared rather than implied, which makes it one of the easiest sources to read accurately.

Download for macOS
v0.1.33 · .dmg · Apple Silicon & Intel
Signed & notarized by Apple · opens without a Gatekeeper warning
sha256 698955a0187bc039f4c74f5d05a9f10fbb27376a45788a0a241d1326b73873c7
Download for Windows instead
$curl -fsSL https://lucidtrain.com/install.sh | sh

What it reads

settings for installed apps, databases, caches and configured third-party services; the URL configuration for the request surface; models for the data layer; and Celery task definitions for asynchronous work. Because Django puts each of these in a conventional place, there is far less inference here than in a framework where wiring happens at startup.

How Django becomes components

Each app is a component, which matches how Django projects are actually reasoned about. Models within an app become its data footprint, and foreign keys across apps become edges, which is the most useful output: cross-app model relationships are exactly where the boundaries that looked clean turn out not to be. Middleware and authentication backends form the request path, and third-party services in settings become external nodes.

Why the layout can be trusted

The agent reads the files listed above and emits a semantic graph: components, the tier each belongs to, and the edges between them, with no coordinates anywhere. The ELK layout engine then computes positions and orthogonal edge routing. This is why the output cannot come back with boxes overlapping or arrows crossing through cards, which is the usual failure when a language model is asked to place things on a canvas itself.

Two diagrams, not one

A Django project has an app architecture and an entity model, and they answer different questions. Drawing them separately keeps both readable, and the entity diagram in particular tends to be the one people keep, since a Django data model is where most of the domain lives.

Your code stays on your machine

It runs on your machine. With a local Ollama model nothing leaves the laptop at all, and with your own API key the file contents go to the provider you chose and never through us. For a source that is your actual codebase, that distinction is usually the deciding one.

Django to diagram

In the projectIn the diagram
INSTALLED_APPSComponents
urls.pyThe request surface
models.pyData tier and the entity model
Cross-app foreign keysEdges between components
Celery tasksWorker components
settings DATABASES and CACHESData tier nodes
Middleware and auth backendsThe request path
Third-party service configurationExternal nodes

The prompt

shell
$ Survey this Django project and draw two diagrams: the app architecture with the request path and background tasks, and the entity model from the models.
FAQ

Questions

Does it need the project to run?

No. It reads files, so it does not need a database, environment variables or a virtualenv.

Will it draw the entity model as well?

Yes, from the models, with cardinality read from the field definitions. It is usually worth generating as its own diagram rather than combining it with the app architecture.

Does it understand Django REST Framework?

Yes. Viewsets and routers read as the API surface, and serializers indicate which models are exposed, which is often more interesting than the model list itself.

What about multiple settings modules?

Point it at the one you care about. Diagramming a base settings module and a production override together mostly illustrates that they differ.

Related