nuke

bun alchemy unsafe nuke [file] [options]

nuke enumerates and deletes every live resource across the stack’s providers. The command nests under unsafe and is deliberately hidden from --help — it’s dangerous and we don’t want agents to discover and use it. This page is its only discovery surface.

Caution

nuke is not scoped to a stack, a stage, or the state store. The stack file is imported only to learn which providers are registered; each provider’s list() then enumerates every resource of that type in the ambient account/region/zone — including resources alchemy never created — and deletes them all. This cannot be undone. What you usually want is alchemy destroy, which is stack-scoped and state-driven.

What it destroys

nuke walks the built provider context and collects every provider that exposes both list and delete — everything those providers can enumerate is a deletion candidate.

The state store is never read or written: enumeration is live cloud state only. State entries are left stale, so follow up with alchemy state clear — see Inspecting State.

What survives

• nuke.singleton settings — always-present configuration (e.g. a zone’s SSL settings) whose delete only resets defaults; excluded at discovery.
• nuke.skip resources — resources with no real delete API; also excluded at discovery.
• Providers filtered out by --include/--exclude.
• Resources spared by a --filter expression.
• Resources whose delete keeps failing — reported at the end of the run.
• Anything owned by providers not registered in the stack file.

Scoping the blast radius

--include and --exclude take provider-ID globs (picomatch, e.g. 'Cloudflare.*'), are repeatable, and --exclude is applied after --include.

bun alchemy unsafe nuke --include 'Cloudflare.Worker' --dry-run --verbose

--filter is a JavaScript expression evaluated with resource in scope (plus synthesized Type and LogicalId fields); a truthy expression spares the resource, and a throwing or non-boolean expression is treated as false. Repeatable.

# spare production workers
bun alchemy unsafe nuke --filter 'resource.workerName.startsWith("prod-")'

Dry run and confirmation

Every run starts with a per-provider report of to-delete and filtered-out counts; --verbose/-v also enumerates each resource by a best-effort display name.

--dry-run exits after the report. Otherwise a confirm prompt — Permanently DELETE N resource(s)? This cannot be undone. — defaults to No and is skipped by --yes. In non-interactive shells, run --dry-run first, then re-run with --yes.

Multi-pass deletion

Deletion runs in passes: each pass attempts every remaining resource, failures are retried in the next pass, and dependency ordering emerges without a graph. The loop stops when a pass makes no progress and reports N resource(s) could not be deleted.

--concurrency bounds how many providers are scanned/deleted in parallel (default 16; 0 = unbounded, which is usually slower because it triggers provider-side rate limiting and retry backoff). Resources within a provider always delete concurrently.

--timeout is a per-provider timeout in seconds for each list/delete call (default 120), so one slow or hanging provider can’t stall the whole run. Scan failures are swallowed — the provider contributes 0 resources — and logged to .alchemy/log/out.

Flags

Option	Description
[file]	Stack file to import (defaults to alchemy.run.ts); used only to discover which providers are registered
--profile <name>	Auth profile to use (defaults to default or $ALCHEMY_PROFILE)
--env-file <path>	Load environment variables from a file
--yes	Skip the confirmation prompt
--dry-run	Report what would be deleted, then exit without deleting
--verbose, -v	List every individual resource that will be deleted, not just per-provider counts
--concurrency <n>	Max number of providers scanned/deleted in parallel (resources within a provider are always deleted concurrently). Use 0 for unbounded. Default: 16 — unbounded tends to be slower because it triggers provider-side rate limiting and retry backoff.
--timeout <s>	Per-provider timeout (seconds) for each list/delete call, so one slow or hanging provider can’t stall the whole run. Default: 120.
--include <glob>	Glob of provider IDs to include (e.g. 'Cloudflare.*' or 'Cloudflare.Worker'). Repeatable; when omitted, every provider is included.
--exclude <glob>	Glob of provider IDs to exclude (applied after --include). Repeatable.
--filter <expr>	JavaScript expression evaluated with resource in scope. Any resource for which an expression is truthy is spared. Repeatable.

Debugging

DEBUG=1 routes provider logs to the console at Debug level and disables the TUI so the log stream isn’t clobbered by the progress renderer; interactive runs otherwise show a scan progress bar followed by per-pass delete progress bars.

Where next

• destroy — the stack-scoped, state-driven teardown you usually want
• Inspecting State — clear the stale state entries nuke leaves behind
• State Store — why nuke bypasses it entirely