Upgrading

Sync your fork

Upgrading is one click. Open your fork on GitHub and choose Sync fork → Update branch. That’s it.

# Same as clicking "Sync fork", from a terminal with the GitHub CLI
gh repo sync <you>/searchkeep --source noobnooc/searchkeep --branch main

Read the changelog or GitHub releases first. Every release that needs anything from you says so at the top.

What happens next

1. Workers Builds sees the new commit on main and starts a build if it touches the watch paths (apps/cloudflare/**, packages/** or pnpm-lock.yaml). Changes that only touch the docs or the website do not rebuild your Worker.
2. The build compiles the Worker and the dashboard.
3. The deploy command tries to apply new D1 migrations remotely, deploys the new Worker version, and never fails because of the migrations. With the default build token, which has no D1 permission, the remote step is skipped.
4. The new Worker applies any pending migrations itself on its first request.
5. Your secrets, the D1 database, the custom domain and Access are untouched.

Because configuration lives in Worker Secrets and the D1 binding has no ID in the repository, your fork has no local changes and syncing never produces a merge conflict. keep_vars: true in wrangler.jsonc also keeps any plain variables you set in the dashboard.

Verify: the build in Workers & Pages → searchkeep → Deployments succeeded, and setup_status still reports ready.

Database migrations

Since every fork deploys automatically on sync, a bad migration would reach everyone at once. Searchkeep treats migrations accordingly:

• Migrations are forward-only and safe to run more than once.
• Whether Wrangler or the Worker applies them, both record them in the same d1_migrations table, so a migration never runs twice.
• CI applies each new migration to a database created by the previous release before it can merge.
• Migration files require review by a maintainer.

Releases with manual steps

Occasionally a release needs something only you can do, such as adding a permission to the Cloudflare API token or setting a new secret. Such releases:

• list the step under Upgrade notes in the changelog and the GitHub release;
• are called out in the pull request that introduced them, so nothing reaches main without an upgrade note.

Rolling back

Cloudflare keeps previous Worker versions. To roll back the code, open Deployments for the searchkeep Worker and roll back to an earlier version, or run npx wrangler rollback --name searchkeep.

Rolling back does not undo database migrations, because migrations are forward-only. Check the changelog before rolling back across a release that includes one. If you need to rewind the data itself, D1 Time Travel can restore the database to an earlier point in time (up to 30 days back on Workers Paid, 7 on Workers Free).

After any upgrade or rollback, run setup_status to confirm everything is still green.

If you changed the code

You are free to modify your fork. If you do, “Sync fork” may report conflicts, which you resolve like any other Git merge. To keep upgrades trivial, prefer configuration over code changes, and consider contributing generally useful changes upstream so they ship to everyone.