1---
2title: Inspecting State
3description: See what alchemy thinks is deployed, debug a bad diff, and recover from bad state.
4---
5
6import Terminal from "../../../components/Terminal.astro";
7
8## What does alchemy think is deployed?
9
10```sh
11bun alchemy state
12```
13
14<Terminal content={`AlchemyEffectWebsite
15├─ dev_sam
16│ ├─ Bucket
17│ └─ Worker
18└─ prod
19 ├─ Bucket
20 └─ Worker`} />
21
22In an interactive terminal, bare `alchemy state` opens the state
23explorer. It is a browsable tree of stacks, stages, and resources with a YAML
24preview of the selected state. This is the record used by the next plan, not
25the live cloud. See [State Store](/state-store). Full flag reference:
26[state](/cli/state).
27
28For scripts, drill down one level at a time with `state list`:
29
30```sh
31bun alchemy state list
32```
33
34Lists every stack in the store.
35
36```sh
37bun alchemy state list myapp
38```
39
40Lists every stage recorded under `myapp`.
41
42```sh
43bun alchemy state list myapp/dev_sam
44```
45
46Prints the state entries tracked under that stack and stage. Pass these paths to
47`state read`.
48
49Or skip the drilling entirely and read the whole estate at once:
50
51```sh
52bun alchemy state read -r | jq 'to_entries[] | select(.value.resourceType == "AWS.EC2.Instance")'
53```
54
55One call returns every record across all stacks and stages as a
56single JSON document to filter locally — see
57[state read](/cli/state#state-read).
58
59## Debugging a bad diff
60
61```sh
62bun alchemy state read myapp/dev_sam/Bucket
63```
64
65This is the persisted props/attrs the planner diffs against — see
66[state](/cli/state) for the output encoding. Compare it with what
67`alchemy plan` says it wants to change. Three usual causes:
68
69**Wrong stage.** `--stage` defaults to `live_$USER` (e.g. `live_sam`),
70so a plan that "wants to create everything" often just means you're
71looking at a stage you never deployed. Run
72`state list myapp` and confirm which stage actually has state.
73
74**Drift.** The cloud changed out-of-band — someone edited the
75resource in a console or another tool. `state read` shows what alchemy
76last persisted; the reconciler converges observed cloud state to the
77desired state on the next deploy (see
78[Resource Lifecycle](/infrastructure-as-code/resource-lifecycle)).
79
80**Stale state from a partially-failed deploy.** If a deploy crashed
81after mutating the cloud but before persisting, the record lags
82reality. Check the persisted attributes against what actually exists
83before reaching for `state delete`.
84
85## Recover from bad state
86
87When the record is beyond repair, delete it and redeploy.
88`state delete` only deletes Alchemy's local record. It does not delete cloud
89resources:
90
91```sh
92# one stage
93bun alchemy state delete myapp/pr-42
94
95# a whole stack
96bun alchemy state delete myapp
97```
98
99Then deploy — resources alchemy owns are re-imported automatically:
100
101```sh
102bun alchemy deploy
103```
104
105If the deploy fails with `OwnedBySomeoneElse`, escalate:
106
107```sh
108bun alchemy deploy --adopt
109```
110
111See [Adopting Resources](/cli/adopting-resources) for why the flag is
112usually unnecessary.
113
114## Orphaned local state
115
116Pass `--backend local` to any `state` subcommand to read the on-disk
117`.alchemy/state` directory instead of the stack's configured store.
118The canonical use: a Cloudflare state-store bootstrap was interrupted
119and left resources recorded only locally.
120
121```sh
122# wipe local state after a botched bootstrap
123bun alchemy state delete myapp --backend local
124```
125
126See [cloudflare](/cli/cloudflare) for bootstrap repair.
127
128## Where next
129
130- [state](/cli/state) — full subcommand and flag reference
131- [Adopting Resources](/cli/adopting-resources) — ownership and `--adopt`
132- [cloudflare](/cli/cloudflare) — state-store bootstrap
133- [State Store](/state-store) — where resource state lives