Update your webhook

Updating is an in-place redeploy of the reference webhook (c-lgrant/tvault, examples/webhook) — there's no migration, no re-keying, and no URL change. Your credentials and your seed are preserved across every deploy, and the webhook upgrades its own storage schema automatically the next time it starts.

Cloudflare deploy-button path (recommended)

If you deployed with the "Deploy to Workers" button, your repo already has an Update webhook GitHub Action.

One-time setup

GitHub blocks Actions from opening pull requests on a brand-new repo by default, so the workflow's first run fails with "GitHub Actions is not permitted to create or approve pull requests." Fix it once:

Settings → Actions → General → Workflow permissions → tick Allow GitHub Actions to create and approve pull requests → Save.

Or with the CLI:

gh api -X PUT repos/<you>/<your-webhook-repo>/actions/permissions/workflow \
  -f default_workflow_permissions=read -F can_approve_pull_request_reviews=true

Running it

1. Your webhook repo → Actions → Update webhook → Run workflow (it also runs on a weekly schedule if you left that enabled).
2. It opens a PR titled chore: update webhook to <version>. Review the diff.
3. Merge it. Cloudflare Workers Builds redeploys automatically against your existing D1 database and seed.

The Action never touches your wrangler.toml, .dev.vars, or secrets — if a release adds a new wrangler.toml variable, the PR won't include it, so check the release notes and add it by hand. Workflow files under .github/workflows/ also can't be auto-updated (GitHub doesn't allow an Actions token to write there); if upstream changed one, the PR body and run summary name it so you can copy it in manually.

Manual path

If you'd rather use the CLI, from a clone of your webhook repo:

# Stage the download OUTSIDE the repo — `git add -A` below would otherwise
# commit the tarball and the whole extracted tree into your PR.
up=$(mktemp -d)
curl -fsSL https://codeload.github.com/c-lgrant/tvault/tar.gz/refs/tags/<tag> -o "$up/up.tgz"
tar -xzf "$up/up.tgz" -C "$up" --strip-components=1
node scripts/apply-update.mjs "$up/examples/webhook" .
git checkout -b chore/update-webhook && git add -A && git commit -m "chore: update webhook to <tag>"
git push origin chore/update-webhook   # open a PR, review, merge → auto-deploy
rm -rf "$up"

Replace <tag> with the release tag you want from the tvault releases page.

Keep your seed

Whichever path you use, never regenerate or lose TV_WEBHOOK_SEED (or your Docker-mounted key files, if self-hosting). It's the one root secret your HMAC signing key and, if you encrypt at rest, your AES-256-GCM key are derived from — losing it loses the ability to decrypt anything already stored, and Token Vault has no copy to hand back.

Self-host / Docker

If you're running the Docker image (ghcr.io/c-lgrant/tvault-webhook:latest) instead of Cloudflare Workers, updating is a normal container redeploy:

1. Pull the new image tag (or re-build from a newer examples/webhook checkout).
2. Restart the container with the same persisted volume mounted — that volume holds the generated HMAC secret and (if enabled) the AES key, so reusing it keeps your existing binding to your Token Vault account alive.
3. On boot, the webhook applies its own storage schema changes automatically — no separate migration step to run.

D1 migrations run on boot

On Cloudflare Workers, schema changes to the D1 database are applied idempotently the first time the new code runs (CREATE TABLE IF NOT EXISTS ... and equivalents) — there's no separate wrangler d1 migrations apply step to remember. The same D1 database and seed are reused across every deploy; nothing re-provisions.

Check it worked

After updating, go to Settings → Webhook (/settings?section=webhook) in Token Vault and check the health status shown there. A healthy check confirms Token Vault can still reach and authenticate against your webhook post-update — if it shows unhealthy, see Webhook unreachable / auth_failed / redirect refused.