Runs Wrangler auth, secret-list, and deploy dry-run checks, but Wrangler deploy --dry-run still executes the project's local build/bundling pipeline and any configured build command or plugins., Run this command only in a trusted Workers repository after reviewing wrangler config, package scripts, and bundler plugins; do not use it to evaluate untrusted submissions., Never run a real deploy or publish, and validate any environment argument before passing it to Wrangler.
Privacy notes
Wrangler output entering the model context can include your account id, worker name, environment name, and secret names (never secret values)., The dry-run build reads source files and may execute project-controlled local code with inherited environment variables, including Cloudflare-related tokens; review the project before running on sensitive accounts., The command writes Wrangler dry-run output to disk and project build tooling may write additional local files.
Author
jony376
Submitted by
jony376
Claim status
unclaimed
Last verified
2026-06-04
Decision playbook
Review trust signals before you adopt
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
Compare context
Selected
0
Current score
78
Baseline
—
Delta
No baseline selected
No major trust-signal divergence detected in the current selection.
Source and provenance checks
Complete
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Done
Source provenance statusRequired
Marked as source-backed.
Done
Metadata reviewed
Registry metadata indicates a reviewed listing.
Done
Safety and privacy checks
Complete
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Done
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Done
Trust level risk gateRequired
Trust level does not block evaluation.
Done
Package and install checks
Needs review
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Done
Package verification flag
No package verification flag provided.
Pending
Checksum metadata
No checksum provided for downloaded artifact.
Pending
Compare-driven decision checks
Needs review
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
Current risk score 16/100. Use staged verification before broader rollout.
Risk 16
Pre-adoption checks
Validate source and review signals before any execution.
Confirm source provenanceRequired
Source URL/provenance metadata is present.
Done
Confirm metadata review state
Listing has review metadata.
Done
Verify install payload
Install/config payload exists and can be inspected.
Done
Security checks
Confirm safety, privacy, and package integrity signals.
Review safety notesRequired
Safety notes are present.
Done
Review privacy notesRequired
Privacy notes are present.
Done
Verify package integrity metadata
No package verification/checksum metadata.
Pending
Rollout
Adopt in controlled steps based on the selected plan.
Run in isolated sandbox firstRequired
Use a constrained sandbox and observe behavior across multiple tasks.
Pending
Roll out graduallyRequired
Roll out to a small cohort before wider usage.
Pending
Set monitoring and fallback
Define rollback path and monitor errors after adoption.
Pending
Evidence readiness
Evidence readiness matrix · balanced
Required evidence gates are covered (5/6 signals complete).
Risk 15
Source provenance
Present
Source repository/provenance is listed.
Required in this preset
Metadata review
Present
Review metadata is present.
Required in this preset
Safety notes
Present
Safety notes are present.
Required in this preset
Privacy notes
Present
Privacy notes are present.
Optional in this preset
Package integrity
Missing
Package integrity metadata is missing.
Optional in this preset
Install payload
Present
Install payload is available.
Required in this preset
Required evidence gates are covered for this preset.
Decision timeline
Decision timeline · balanced
5/6 steps complete with no blocking gaps for this preset.
Risk 14
triage
Confirm source provenanceRequired
Source/provenance metadata is available.
Done
triage
Check metadata review statusRequired
Review metadata is available.
Done
verify
Review safety notesRequired
Safety notes are available.
Done
verify
Review privacy notes
Privacy notes are available.
Done
verify
Validate package integrity metadata
Package integrity metadata is missing.
Pending
rollout
Verify install payload and commandsRequired
Install payload is available.
Done
No required blockers for this timeline preset.
Safety & privacy surface
Safety & privacy surface
3 safety and 3 privacy notes across 3 risk areas. Review closely: credentials & tokens.
3 areas
SafetyCredentials & tokensRuns Wrangler auth, secret-list, and deploy dry-run checks, but Wrangler deploy --dry-run still executes the project's local build/bundling pipeline and any configured build command or plugins.
SafetyExecution & processesRun this command only in a trusted Workers repository after reviewing wrangler config, package scripts, and bundler plugins; do not use it to evaluate untrusted submissions.
SafetyExecution & processesNever run a real deploy or publish, and validate any environment argument before passing it to Wrangler.
PrivacyCredentials & tokensWrangler output entering the model context can include your account id, worker name, environment name, and secret names (never secret values).
PrivacyCredentials & tokensThe dry-run build reads source files and may execute project-controlled local code with inherited environment variables, including Cloudflare-related tokens; review the project before running on sensitive accounts.
PrivacyLocal filesThe command writes Wrangler dry-run output to disk and project build tooling may write additional local files.
Safety notes
Runs Wrangler auth, secret-list, and deploy dry-run checks, but Wrangler deploy --dry-run still executes the project's local build/bundling pipeline and any configured build command or plugins.
Run this command only in a trusted Workers repository after reviewing wrangler config, package scripts, and bundler plugins; do not use it to evaluate untrusted submissions.
Never run a real deploy or publish, and validate any environment argument before passing it to Wrangler.
Privacy notes
Wrangler output entering the model context can include your account id, worker name, environment name, and secret names (never secret values).
The dry-run build reads source files and may execute project-controlled local code with inherited environment variables, including Cloudflare-related tokens; review the project before running on sensitive accounts.
The command writes Wrangler dry-run output to disk and project build tooling may write additional local files.
Schema details
Install type
cli
Troubleshooting
No
Source repository stats
Scope
Source repo
Runtime and command metadata
Command syntax
/deploy-readiness [environment]
Full copyable content
/deploy-readiness [environment]
About this resource
The /deploy-readiness command runs a pre-flight check for a Cloudflare Workers project using the Wrangler CLI, so build failures, missing secrets, and config gaps surface before a real deploy — not after.
Usage
/deploy-readiness [environment]
With an environment (a Wrangler named environment): check that environment's config.
Without an argument: check the top-level config.
What it does
When you invoke this command, follow these steps and never run a real deploy:
Confirm trust first. Before running Wrangler, confirm the repository is trusted and review wrangler.toml / wrangler.jsonc / wrangler.json, package scripts, and bundler/plugin config for build hooks. If the project is untrusted or the user only wants a static review, skip the dry-run and report that it can execute local project code.
Validate the environment argument. If an environment is provided, accept only a Wrangler environment name matching ^[A-Za-z0-9_-]+$; otherwise stop and ask for a safe environment name. Pass it as a separate --env argument, not by interpolating a shell string.
Confirm auth. Run wrangler whoami. If it fails, stop and report that the user must run wrangler login (or set CLOUDFLARE_API_TOKEN).
Validate config. Read wrangler.toml / wrangler.jsonc / wrangler.json and confirm name, main, and compatibility_date are present. Flag a missing compatibility_date as a reproducibility risk.
Dry-run the build only after the trust review passes. Run wrangler deploy --dry-run --outdir /tmp/wrangler-dry (add the validated environment as separate --env and value arguments when given). This compiles and bundles the worker locally and surfaces TypeScript/bundler errors without uploading anything, but it can execute project-controlled build commands and plugins with your local privileges and inherited environment variables.
Check secrets. List configured secrets with wrangler secret list (and the validated --env arguments when given), grep the source for env.<NAME> references, and report any referenced secret that is not configured.
Check bindings. Confirm every KV namespace, R2 bucket, D1 database, queue, and service binding referenced in code is declared in the config.
Report go / no-go. Summarize each check as pass or fail and give a single readiness verdict with the exact command to fix any failure.
Output format
Auth: account + whether authenticated.
Config: name / main / compatibility_date status.
Build: dry-run result (and the first error if it failed).
Secrets: referenced vs configured, with any gaps.
Bindings: declared vs referenced.
Verdict: ready to deploy, or blocked with the fixes.
Requirements
Wrangler CLI installed (npm i -g wrangler or npx wrangler).
An authenticated Wrangler session (wrangler login) or CLOUDFLARE_API_TOKEN set.
Run from the worker project root so the config and source are discoverable.
Safety notes
The command never runs a real deploy, edits secrets, or changes bindings. However, wrangler deploy --dry-run is not safe for untrusted projects: it still runs the local Workers build and bundling pipeline, including configured build commands, package scripts, and plugins. Run it only in trusted repositories after reviewing local build hooks, and validate the optional environment name before passing it to Wrangler.
Privacy notes
Wrangler output included in the model context can contain your account id, worker name, environment name, and secret names (never values). The dry-run build reads source files and may execute project-controlled local code with inherited environment variables, including Cloudflare-related tokens. Wrangler writes dry-run output to disk, and project build tooling may create or modify additional local files.
Show that /deploy-readiness - Cloudflare Deploy Readiness Command for Claude Code is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/commands/cloudflare-deploy-readiness)
How it compares
/deploy-readiness - Cloudflare Deploy Readiness Command for Claude Code side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
2 trust signals differ across this comparison (Source provenance, Submitter).
Next steps differ across entries — use the actions in the table below to copy install commands and source links per resource.
Source-backed agent for reviewing Cloudflare Workers deployments before production release, covering wrangler config, bindings, routes, secrets, compatibility flags, and rollback plans aligned to official Cloudflare docs.
✓Runs Wrangler auth, secret-list, and deploy dry-run checks, but Wrangler deploy --dry-run still executes the project's local build/bundling pipeline and any configured build command or plugins.
Run this command only in a trusted Workers repository after reviewing wrangler config, package scripts, and bundler plugins; do not use it to evaluate untrusted submissions.
Never run a real deploy or publish, and validate any environment argument before passing it to Wrangler.
✓Workers deployments can change live traffic immediately; treat production deploy review as release-impacting work requiring explicit approval.
Do not run production deploy commands from unreviewed forks or unverified CI workflows with Cloudflare API tokens.
Bindings to production KV, R2, D1, or Queues can cause data loss or cross- environment contamination if environment names are wrong.
Wrangler rollback and versions features reduce but do not eliminate blast radius; verify rollback steps before deploy.
✓This hook is static and read-only. It reads only non-symlinked Wrangler config files inside the current project and does not run `wrangler deploy`, `wrangler dev`, `wrangler whoami`, `wrangler secret list`, package scripts, build plugins, or network commands.
The hook exits non-zero only for parse failures or missing required top-level Worker fields such as `name` and `compatibility_date`; warnings remain advisory so the user can review them.
The TOML checks are heuristic and do not replace Wrangler's own parser or a trusted pre-deploy dry run. Use them as a fast edit-time guard, then run official Wrangler validation in a trusted repository.
Do not expand this hook into a dry-run deploy hook unless the team has reviewed local build-script execution, inherited environment variables, and output-directory cleanup.
Keep matchers scoped to config file edits. Running config checks after every tool call adds noise without improving Cloudflare safety.
✓Wrangler deployment and rollback commands mutate live Worker traffic; verify account, Worker name, route, and environment before running them.
The archive URL points to Cloudflare's external Workers SDK tag archive; pin versions and review release provenance before using it in CI.
Use least-privilege API tokens and secret stores; never commit `.dev.vars`, `.env`, tokens, account credentials, or CI secret values.
Version rollback can restore Worker code/config traffic but does not restore bound KV, R2, D1, Durable Object, queue, or downstream service state.
Trigger and route updates can change public reachability; treat them as separate release steps with explicit verification.
Privacy notes
✓Wrangler output entering the model context can include your account id, worker name, environment name, and secret names (never secret values).
The dry-run build reads source files and may execute project-controlled local code with inherited environment variables, including Cloudflare-related tokens; review the project before running on sensitive accounts.
The command writes Wrangler dry-run output to disk and project build tooling may write additional local files.
✓Wrangler configs, Worker logs, and binding metadata can expose account IDs, internal hostnames, customer routes, and secret names.
Workers observability logs may contain request payloads, auth headers, and user identifiers; redact before sharing review notes externally.
API tokens and OAuth client secrets must not appear in prompts, PR comments, or generated review output.
Third-party observability exports remain subject to vendor retention policies separate from Cloudflare account settings.
✓The hook reads `wrangler.toml`, `wrangler.json`, or `wrangler.jsonc` only inside the current project, with symlinks rejected and a 1 MiB size cap.
Wrangler config files can contain worker names, route patterns, account identifiers, resource IDs, binding names, environment names, analytics settings, and non-secret vars.
Hook output may include file paths, config key names, environment names, and secret-like variable names, so avoid pasting terminal logs into public issue comments without review.
If a Wrangler config currently contains real secrets in `vars`, the hook can reveal the key names and the surrounding configuration context. Move sensitive values to Wrangler secrets before sharing output.
✓Wrangler deploy uploads bundled Worker source, static assets, and configuration metadata to the target account.
Release logs can include request URLs, headers, exception details, route names, account IDs, and zone IDs; redact before sharing publicly.
CI deploys rely on API tokens and account IDs; avoid printing environment dumps, secret values, or full request payloads in logs.
Worker routes, custom domains, and account metadata can reveal infrastructure topology; keep public notes minimal and intentional.
Prerequisites
— none listed
Worker source repository with wrangler config, routes, and environment definitions for staging and production.
Cloudflare account access to inspect bindings (KV, R2, D1, Queues, AI, etc.), routes, and deployment history.
CI or local Wrangler deploy command output from a staging dry run when available.
Maintainer approval path before production deploy or traffic shift.
Claude Code project where hooks are allowed by user or project policy.
Cloudflare Workers or Pages project with `wrangler.toml`, `wrangler.json`, or `wrangler.jsonc` checked into the repository.
`jq` available locally to parse Claude Code hook input.
Node.js available locally for static JSON/JSONC/TOML heuristics.
Wrangler-managed Worker project or release plan
Project-local Node.js toolchain that satisfies the pinned Wrangler package engines
Access to account ID, Worker name, environment name, route, and binding inventory
CI or local authentication plan for non-interactive deploys