Docs & Code Guide

A living diagram from Pulumi: the stack export is the reliable source when programs build resources dynamically

Pulumi programs are real code. A TypeScript loop can create ten queues from a config array, a Python conditional can add a bastion host only in staging, and no static reading of the program can tell you what actually got built. The stack knows. pulumi stack export dumps every resource the engine manages, which makes it the source a living architecture diagram should regenerate from, one export after every pulumi up.

8 min readFor teams running Pulumi programs in TypeScript or Python

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

216/20003 credits left
Try:

No account needed · Editable canvas, not a picture

Why the program is the wrong source

With HCL-style declarative tools, the config file enumerates the resources. With Pulumi, the program computes them: resources appear inside loops, behind conditionals, and from component classes that expand into many children at runtime. Two runs of the same program with different stack config produce different infrastructures, on purpose. Any diagram generated by reading the .ts or .py files is a guess about what the code would do, not a record of what it did.

The engine, meanwhile, keeps a complete record. Every resource Pulumi manages lands in the stack's checkpoint with its URN, type, parent, and dependencies. Diagramming Pulumi well means diagramming that record.

Three artifacts the CLI hands you

pulumi stack export writes the full checkpoint as JSON: the resource list with URNs, types, parent relationships, and dependency edges, everything a diagram needs and nothing it has to infer. pulumi preview --json is the forward-looking version, the planned creates, updates, and deletes before a deploy, useful when you want the diagram change reviewed alongside the code change. And pulumi stack graph writes the stack's dependency graph as Graphviz DOT if you want the raw shape.

One security note that works in Pulumi's favor: secret outputs in the export stay encrypted by the stack's secrets provider unless you explicitly pass --show-secrets. A default export is therefore a reasonably safe artifact to hand to an agent, since the topology is plaintext and the secrets are not.

# The full checkpoint: every resource, URN, parent, dependencies
pulumi stack export --file stack.json

# Planned changes before deploy, machine readable
pulumi preview --json

# The dependency graph as Graphviz DOT
pulumi stack graph deps.dot

One stack per environment, one diagram per truth

The Pulumi convention of a stack per environment, dev, staging, prod, settles a question other tools leave open: which environment does the wiki diagram show? Pick the stack, usually prod, export it, and label the diagram with the stack name. When staging genuinely differs, that bastion host again, the difference is visible by exporting both stacks rather than assumed from reading the code.

Parent relationships in the export give the grouping. Component resources, the classes your team wrote to bundle a service with its bucket and its alerts, appear as parents of their children, so the diagram can draw each component as a zone and match the abstractions the program authors actually meant.

Regenerate in the same job as pulumi up

The loop is one step after the deploy: pulumi up, then pulumi stack export, then an agent connected to Datadef's MCP server (registry io.datadef/mcp) reads the export and updates the diagram, new resources added, destroyed ones removed, component zones intact. The agent connection needs an API key, available on paid plans; setup lives in the MCP diagram server guide.

Datadef does not watch the repo or the Pulumi service, and nothing triggers on its own. The regeneration is one command next to the one you already run. For the first diagram, before there is anything to update, the infrastructure-as-code diagram generator takes a pasted export or a plain-English description and gives you the editable starting point.

With the diagram public, the wiki side is automatic: the embed image serves with a five minute cache lifetime, so a diagram updated by the pipeline shows up in the docs within minutes.

Limits of the export view

The Pulumi Cloud console already lists every resource in a stack, and for inspecting one deployment right after it runs, that list is the fastest tool. What it is not is a curated architecture view at the altitude a wiki needs, drawn once and embedded where the team reads.

The Datadef embed exists only for projects shared public; private projects have no embed URL, so confidential stacks fall back to exported images. And the loop covers the diagram, not the prose: runbooks and per-stack README files are out of scope, a different discipline with different tooling.

Export first, always

Any workflow that diagrams Pulumi from source code inherits the dynamic-resource problem. Export the stack and the problem does not exist.

FAQ

How do I visualize a Pulumi stack?

Export it. pulumi stack export writes the checkpoint as JSON with every resource, its type, parent, and dependencies; pulumi stack graph writes the same shape as Graphviz DOT. Feed either to a diagram tool or an MCP-connected agent to get an architecture view, then re-run the export after each pulumi up to keep the view current.

Why not generate the diagram from the Pulumi program code?

Because the program computes resources at runtime. Loops, conditionals, and component classes mean the resource set depends on stack config, so static reading of TypeScript or Python is a guess. The stack checkpoint records what was actually created, which is what a diagram should show.

Does pulumi stack export leak secrets?

By default, no. Secret outputs remain encrypted by the stack's secrets provider in the exported JSON; they are only decrypted if you pass --show-secrets. That makes the default export a reasonably safe artifact for diagram generation, since topology is readable and secret values are not.

Should the diagram cover all environments or one stack?

One stack per diagram, following Pulumi's stack-per-environment convention. Label the diagram with the stack name, usually prod for the wiki. If staging differs in ways that matter, export it separately; a real second diagram beats one diagram silently blending two environments.

Does the diagram update by itself after pulumi up?

No. Datadef does not watch repositories or the Pulumi service. You add one step after pulumi up in CI: export the stack and have an MCP-connected agent update the diagram. Wiki pages embedding the diagram then refresh within minutes without being touched.