Update the CMS

Kenresoft CMS ships as numbered releases such as v0.9.0 and v0.9.1. Updating means moving your deployment from the release it runs to a newer one. It is always the same command, run in the CMS project you created with npm create and deployed with pnpm run setup:

pnpm run update

Setup once, update from then on

pnpm run setup is for the first deployment only. Every later release is installed with pnpm run update, which never touches your secrets, database, storage or domains. See Set up and deploy.

Update to the latest release

1. See whether there is a new release. In the admin, open Settings → Updates. It shows the version you run and, when a newer release exists, which one. Admins and Owners also see an Update available notice in the sidebar.

2. Read what changed. Open the Changelog and read every release between yours and the latest. Look for Breaking and Migration sections: they tell you about anything you need to do.

3. Run the update in the CMS project:

   cd my-cms
   pnpm run update

4. Check the result. Reload Settings → Updates; it now shows the new version and Up to date. If the admin looks broken right after the deploy, wait a few minutes and hard-refresh (see below).

What the update does

Step	What you see
Fetches the releases from the upstream remote and picks the latest	✓ Latest release: v0.9.1
Merges that release into your project, keeping your local wrangler.toml edits	✓ Code updated: v0.9.0 → v0.9.1.
Prints the changelog for every release you skipped	What's new since v0.9.0:
Installs dependencies, applies new database migrations	Applying any new database migrations...
Redeploys the API Worker, then rebuilds and redeploys the Admin Worker	✓ API redeployed: …, ✓ Admin redeployed: …

It does not change secrets, BETTER_AUTH_URL, email, CORS or other configuration, create or re-provision D1 or R2, or touch your website or any Astro project.

When you already run the latest release, it prints ✓ Already up to date with v0.9.1 and only redeploys.

Update to a specific release

pnpm run update -- --version 0.9.1

Useful when you want to stay one release behind, or move up one release at a time. The version must exist on the releases page. pnpm run update never moves an install to an older release, because database migrations only run forwards; see Rolling back.

Test unreleased code

A staging install can follow a branch instead of releases, to try changes before they are released:

pnpm run update -- --branch develop

Set UPDATE_BRANCH=develop in your shell to make that the default. Don’t do this on a production deployment: unreleased code can change or break without notice.

An install that follows a branch is ahead of the latest release. When you go back to plain pnpm run update, it stays where it is (Already up to date) until a release catches up with it, then continues with releases as normal.

--version and --branch apply only to the code update. They can’t be combined with each other or with a configuration flag.

Change one configuration area

These flags change configuration only. They do not pull code, install dependencies or run migrations. Use exactly one per run.

Command	Changes	Then
pnpm run update -- --auth	BETTER_AUTH_URL (after a confirmation)	Redeploys the API, then rebuilds and redeploys the Admin
pnpm run update -- --email	EMAIL_PROVIDER, EMAIL_FROM, RESEND_API_KEY secret	Redeploys the API
pnpm run update -- --domain	API custom domain route	Redeploys the API
pnpm run update -- --admin-domain	Admin custom domain route and the ADMIN_URL secret	Deploys the Admin Worker
pnpm run update -- --turnstile	TURNSTILE_SECRET_KEY secret and TURNSTILE_SITE_KEY	Redeploys the API only if the site key changed
pnpm run update -- --storage	Nothing. Shows the R2 bucket status	None
pnpm run update -- --database	Nothing. Shows the D1 status	None

Each command shows the current value first; secrets are only ever reported as configured or not. --storage and --database are status-only: repointing a binding moves no data, so there is no safe default action.

Add --ci to run a flag non-interactively. It reads *_NEW variables (BETTER_AUTH_URL_NEW, EMAIL_PROVIDER_NEW, EMAIL_FROM_NEW, RESEND_API_KEY_NEW, CUSTOM_DOMAIN_NEW, DISABLE_WORKERS_DEV, ADMIN_CUSTOM_DOMAIN_NEW, TURNSTILE_SECRET_KEY_NEW, TURNSTILE_SITE_KEY_NEW, and TURNSTILE_DISABLE=true to remove Turnstile). An unset variable always means “leave unchanged”.

Safety checks

• Refuses to run if wrangler.toml has no database_id: setup never completed, or a merge overwrote it.
• Refuses to redeploy over a Worker of the same name that is bound to a different D1 database, since Cloudflare would silently overwrite another deployment. Run pnpm run setup to pick a new name.
• Never regenerates BETTER_AUTH_SECRET, so users stay signed in.
• Stashes your uncommitted local changes (usually wrangler.toml) before merging and restores them afterwards.
• If there is no upstream remote, skips the code pull with a note and redeploys what is on disk.

Older installs

An install scaffolded before the switch to a real Git clone has no shared history with the CMS repository. Its first update explains this and asks before doing a one-time reconciliation merge, and restores your wrangler.toml to what you had committed just before it.

An install that was updated before releases existed (before v0.9.0, September 2026) followed the develop branch. If it is ahead of the latest release, it stays where it is until the next release, then follows releases.

After an admin deploy

Cloudflare’s edge cache may briefly serve the previous admin index.html, which references an old bundle. It corrects itself within minutes and does not mean the deploy failed.

An external Astro site is updated separately. See Astro deployment.

Problems? See Update troubleshooting.