# Deploy Verify

> Deploy Cloudflare Workers and verify changes work in staging/preview. Use when asked to "deploy", "ship", "push to staging", "deploy and test", "verify deploy", or "check staging".

- Skill: `jonmumm/deploy-verify` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jonmumm/deploy-verify`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jonmumm/deploy-verify/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: jonmumm (https://skillmd.com/u/jonmumm)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jonmumm/deploy-verify

---


# Deploy & Verify

Deploy Cloudflare Workers to an environment and verify the changes work by inferring what to test from recent git changes.

## Workflow

```
1. Pre-deploy checks
2. Deploy to target environment
3. Infer verification plan from git diff
4. Run verification
5. Report results (pass/flag issues)
```

## Step 1: Pre-Deploy Checks

Before deploying, verify:

1. **Types pass** — `tsc --noEmit` or project equivalent
2. **Tests pass** — `npm test` / `bun test` / project equivalent
3. **No uncommitted changes** — `git status` should be clean (warn if dirty)
4. **Detect environment config** — read `wrangler.toml` / `wrangler.jsonc` for available environments

```bash
# List available environments from wrangler config
grep -E '^\[env\.' wrangler.toml | sed 's/\[env\.\(.*\)\]/\1/'
```

## Step 2: Deploy

```bash
# To a named environment (staging, preview, etc.)
wrangler deploy --env <environment>

# To production (default if no --env)
wrangler deploy
```

If the project has multiple Workers (monorepo), detect which one changed:
- Check `git diff --name-only` for paths matching Worker directories
- Only deploy the Worker(s) that changed

## Step 3: Infer Verification Plan

This is the key step. Look at what changed and determine what to verify:

```bash
# What changed since last deploy?
git diff HEAD~1 --name-only
git diff HEAD~1 --stat
git log HEAD~1..HEAD --oneline
```

**Inference rules:**

| Change type | What to verify |
|---|---|
| API route handler changed | Hit that endpoint, check response shape and status |
| Middleware changed | Test requests that flow through it |
| Auth logic changed | Test both authenticated and unauthenticated requests |
| KV/D1/R2 bindings changed | Test read/write operations on those bindings |
| Environment variables referenced | Verify secrets are set: `wrangler secret list --env <env>` |
| CORS or headers changed | Check response headers |
| Error handling changed | Test error paths |
| New route added | Hit the new route, verify 200 + correct response |
| Route removed | Verify it returns 404 |
| Static assets changed | Fetch them and verify content |

## Step 4: Run Verification

Use `curl` or `fetch` to test the deployed URL:

```bash
# Basic health check
curl -s -o /dev/null -w "%{http_code}" https://<worker-url>/

# Check specific endpoint with response body
curl -s https://<worker-url>/api/endpoint | jq .

# Check response headers
curl -sI https://<worker-url>/api/endpoint

# POST with body
curl -s -X POST https://<worker-url>/api/endpoint \
  -H "Content-Type: application/json" \
  -d '{"key": "value"}'
```

Also check wrangler logs for errors after hitting endpoints:

```bash
# Tail logs (run in background, hit endpoints, then check)
wrangler tail --env <environment> --format json
```

## Step 5: Report

**If all checks pass:**
```
Deploy verified:
- Environment: staging
- URL: https://my-worker-staging.example.workers.dev
- Checks passed:
  - GET /api/stories → 200, response shape correct
  - POST /api/generate → 200, returns stream
  - KV read/write → working
```

**If issues found (flag, don't rollback):**
```
Deploy issues found:
- Environment: staging
- URL: https://my-worker-staging.example.workers.dev
- PASS: GET /api/stories → 200
- FAIL: POST /api/generate → 500
  - Error in logs: "Missing AI binding"
  - Likely cause: AI binding not configured in staging env
- Action needed: Check wrangler.toml [env.staging] AI bindings
```

Do NOT automatically rollback. Flag the issues and let the user decide.

## Multi-Environment Patterns

Common setup:
```toml
# wrangler.toml
name = "my-worker"

[env.staging]
name = "my-worker-staging"
route = "staging.example.com/*"

[env.production]
name = "my-worker"
route = "example.com/*"
```

**Default flow**: Deploy to staging → verify → user promotes to production.
**Direct to prod**: Only when user explicitly asks. Still run verification after.

## Secrets

If verification fails with auth/config errors, check that secrets match between environments:

```bash
wrangler secret list --env staging
wrangler secret list --env production
```

Secrets don't copy between environments. A common gotcha after adding a new env.

## Troubleshooting

| Problem | Fix |
|---------|-----|
| 500 after deploy | `wrangler tail --env <env>` to see error logs |
| Binding not found | Check wrangler.toml — bindings must be declared per environment |
| Secret missing | `wrangler secret put <NAME> --env <env>` |
| Old code still serving | Worker may be cached — wait 30s or check `wrangler deployments list` |
| Route not matching | Verify route patterns in wrangler.toml match the URL you're hitting |
| CORS errors | Check if the Worker sets appropriate CORS headers for the origin |

## Gotchas

- **Always verify the deployed version matches your expected commit.** Run `wrangler deployments list` to confirm your code actually deployed. Cached old versions are a common false trail.
- **Don't strip `console.log` in production builds.** You need logs for debugging — if you can't see what's happening, you can't fix what's broken. Keep logging in production, especially during early development.
- **Secrets don't copy between environments.** Adding a secret to production doesn't add it to staging. After creating a new environment, run `wrangler secret list --env <env>` to verify ALL required secrets are set.
- **Check both `.dev.vars` AND GitHub Actions secrets.** They are independent — a secret in `.dev.vars` only works locally. GH Actions needs its own secrets configured.
- **Deployed URL might not match what you expect.** If using custom domains, verify the route pattern in `wrangler.toml` matches the URL you're testing. Preview deployments use different URLs than production.
- **After deploy, wait 30 seconds before testing.** Workers edge cache can serve stale responses briefly. If you see old behavior, wait and retry before debugging.