Skip to content
alchemy

Deploy and Destroy

When you run alchemy deploy, Alchemy goes through three steps: plan, approve, and apply.

Plan

Section titled “Plan”

Alchemy compares the desired state (your code) against the current state (persisted from the last deploy) and computes a diff:

  • Create (+) — resource exists in code but not in state
  • Update (~) — resource exists in both but properties changed
  • Delete (-) — resource exists in state but not in code
  • No-op (•) — resource is unchanged
Plan: 1 to create, 1 to update

+ Queue (AWS.SQS.Queue)
~ Worker (Cloudflare.Worker)
• Bucket (Cloudflare.R2Bucket)

The plan runs each resource’s diff function to determine whether a property change requires an update, a replacement, or can be ignored.

Approve

Section titled “Approve”

By default, Alchemy shows the plan and asks for confirmation before applying. In CI or scripts, use --yes to skip the prompt:

Terminal window
alchemy deploy --yes

Use --dry-run (or alchemy plan) to see the plan without applying:

Terminal window
alchemy plan

Apply

Section titled “Apply”

After approval, Alchemy executes the lifecycle operations in dependency order:

  1. Resources with no dependencies are created/updated first
  2. Resources that depend on others wait for their dependencies
  3. Outputs are resolved as resources complete

Each operation calls the resource’s provider — create, update, or delete — and persists the resulting state.

Destroy

Section titled “Destroy”

alchemy destroy computes a plan where every existing resource is marked for deletion. Resources are removed in reverse dependency order — dependents are deleted before the resources they depend on.

Plan: 2 to delete

- Worker (Cloudflare.Worker)
- Bucket (Cloudflare.R2Bucket)

Proceed?
◉ Yes ○ No
✗ Worker (Cloudflare.Worker) deleted
✗ Bucket (Cloudflare.R2Bucket) deleted

Replacement

Section titled “Replacement”

When a property change can’t be applied as an in-place update, the resource is replaced:

  1. A new resource is created with a new instance ID
  2. Downstream resources are updated to reference the new resource
  3. The old resource is deleted

The provider’s diff function decides when replacement is needed (e.g. changing a DynamoDB table’s partition key).

Error handling

Section titled “Error handling”
  • Retryable errors (dependency violations, eventual consistency) are retried automatically with backoff
  • Non-retryable errors (validation, authorization) fail immediately
  • Idempotent operations — create and delete are designed to be safe to retry after partial failures