Topology Graph

Run wd graph when you need to see how everything connects. Especially helpful if you’re new to the project, reviewing someone else’s PR, or trying to figure out why a binding is broken.

Usage

$ wd graph
[worker] api
├── (binding: DB) [d1] payments-db
├── (binding: TOKEN_KV) [kv] token-kv
├── (producer: OUTBOX_QUEUE) [queue] payment-outbox
└── (service-binding: WORKFLOWS) [worker] batch-workflow
[worker] batch-workflow
├── (binding: DB) [d1] payments-db
├── (binding: CACHE_KV) [kv] cache-kv
└── (producer: OUTBOX_QUEUE) [queue] payment-outbox
[worker] event-router
├── (binding: DB) [d1] payments-db
├── (producer: OUTBOX_QUEUE) [queue] payment-outbox
└── (consumer) [queue] payment-outbox
[queue] payment-outbox
└── (dead-letter) [queue] payment-outbox-dlq

Resources:
  • [d1] payments-db
  • [kv] token-kv
  • [kv] cache-kv
  • [queue] payment-outbox-dlq

Formats

$ wd graph --format mermaid    # paste into PR comments, Notion, docs
$ wd graph --format dot        # render with Graphviz (dot -Tpng)
$ wd graph --format json       # pipe into other tools

Mermaid output for a PR comment:

$ wd graph --format mermaid
graph TD
  subgraph Workers
    workers_api([api])
    workers_batch_workflow([batch-workflow])
    workers_event_router([event-router])
  end
  subgraph Queues
    payment_outbox[/payment-outbox\]
    payment_outbox_dlq[/payment-outbox-dlq\]
  end
  workers_api -->|WORKFLOWS| workers_batch_workflow
  workers_api -->|OUTBOX_QUEUE| payment_outbox
  payment_outbox -. DLQ .-> payment_outbox_dlq

Live state overlay

When --stage is provided, the graph shows resource lifecycle status from state:

$ wd graph --stage staging
[worker] api → https://api.staging.example.com [STATUS: deployed]
├── (binding: DB) [d1] payments-db [STATUS: observed]
├── (binding: TOKEN_KV) [kv] token-kv [STATUS: observed]
├── (producer: OUTBOX_QUEUE) [queue] payment-outbox [STATUS: observed]
└── (service-binding: WORKFLOWS) [worker] batch-workflow [STATUS: existing]

Each resource shows its lifecycle status:

Status	Meaning
creating	Create command sent, waiting on first response
created	Successful initial provision
updating	Update detected, applying changes
observed	Matches the desired state in Cloudflare
missing	Resource deleted in Cloudflare but not unlinked
unknown	State file missing or unreadable

This is useful for diagnosing drift, reviewing what changed in the last deploy, or auditing resource state across stages.