Production and deployment

Complete the production review

Review compatibility dates, runtime limits, costs, permissions, storage semantics, recovery, and ownership before calling Link Vault production-ready.

Link Vault works. Before I call anything production-ready, I go through a review where every item points at a command I ran, a link I can open, or an output I saved.

One warning first. Limits, prices, and defaults on Cloudflare change often. Numbers copied last year are wrong this year. Open the current docs while you do this.

The list

  • Compatibility date. Recent, and the tests passed after the last bump.
  • Bindings. Which real resource production points at, and who owns it.
  • Environments. Staging and production are separate Workers with their own databases, buckets, and secrets.
  • Secrets. wrangler secret list --env production shows every name the code reads, nothing else.
  • Limits. CPU time, request size, D1 size, KV value size, queue message size, against today’s docs.
  • Pricing. A month at ten times expected traffic, with a budget alert.
  • Cache semantics. The app is correct when KV returns a stale value, and you tested it.
  • D1 recovery. You restored the database once on staging.
  • Queue retries. max_retries is set, a dead-letter queue exists, and someone looks at it.
  • R2 lifecycle. Old exports get deleted, and you know by which rule.
  • Logs and alerts. Workers Logs is on, and a 5xx spike pages a real person.
  • Rollback. You ran wrangler rollback on staging this week and the smoke test passed.

Turn checkboxes into evidence

A checked box means nothing six months later. Next to each item, write the evidence: version ID, binding names and owners, date of the last restore test, smoke test output, alert destination, and who runs the recovery. No evidence means not done.

Look at the failures as a system

Each lesson taught one failure. Now read them together. A code rollback doesn’t restore data. Cache invalidation isn’t immediate. Queue messages can arrive twice. A revoked secret can break the version you roll back to. Ask what happens when two hit at once.

Remove what you don’t use

Every unused binding, route, secret, and permission is a door nobody watches. Delete the practice secret and the debug route from module two. Narrow API tokens to the one Worker that needs them.

Let someone else run it

Hand the runbook to someone who didn’t write the code. Watch them deploy, create and export one link, find both events in the logs, and roll back. Every place they get stuck is a documentation hole.

Now run this review against staging: deploy, create and export a link, find the request and the job in Workers Logs by ID, roll back, and rerun the smoke test. Write the evidence down as you go.

Lesson completed