Docs

Updating Your Instance

Bring a new release into your instance with the guided update helper, which keeps your secrets and customizations, leaves your data untouched, and prints your exact deploy and migration steps.

Last updated July 3, 2026

Because you own the source, updates happen on your terms. There is no forced upgrade window and no vendor pushing a change into your live community overnight. When a new release ships, you download it, review it, and apply it with a guided helper that walks you through every step. This page covers doing that safely.

How a New Release Reaches You#

The download you received is a clean copy of the code. It has no connection back to a central repository, so there is nothing to pull from. When a new version ships, you download the new package the same way you got your first one, unzip it, and point the update helper at that new folder. The helper brings the new code into your instance while carefully keeping the parts that are yours.

That is the whole model. You are never merging against a live remote and you are never at the mercy of an automatic push. A new version is just a new download that you choose to apply when you are ready.

Your Data Is Never Touched#

Your members, posts, courses, events, and settings live in your database, not in these code files. Updating the code cannot change a single row of your data. This is the single most reassuring fact about an update and it is worth internalizing before you start. The helper copies new code over old code and never reaches into your data.

Because of this, a code update and a data change are two different things. Most releases are code only. When a release does need a data change, it says so plainly and the helper prints the exact command for you to run yourself, when you are ready, after the code is in place.

The Update Helper#

Your download ships with a guided helper you run from your project folder.

npx pnpm run update

Use the word run. A bare pnpm update is a different, built-in command that updates your dependency versions, which is not what you want here. The run keyword is what points at the guided helper.

Here is what the helper does for you, in plain terms.

It shows you what is new by reading the changelog that ships in the download.
It looks at the new folder you point it at and builds a preview of exactly which files it would bring in and which it would leave alone.
It keeps your secrets, your version history, your installed dependencies, and any file you have customized. Your environment file with your keys in it is never overwritten.
It shows you that full preview and waits for you to type yes before it copies anything.
It never deletes a thing. It only lays new code over old code.
It never deploys, never runs a data change, and never touches your database. It prints those next steps for you to run yourself.

A few flags are worth knowing.

--dry-run previews everything and copies nothing, so you can look before you leap.
--from path/to/new-version points the helper straight at the unzipped new folder so it does not have to ask.

Running an Update, Step by Step#

Back up first. Take a fresh data export and confirm your secrets are saved somewhere safe. See Backups and Data Ownership.
Read the changelog. Know your current version and the new one, and read what changed between them. Look for anything flagged as manual or requiring a data change.
Download and unzip the new version somewhere you can find it, the same way you got your first download.
Preview the change without touching anything.
```
npx pnpm run update -- --dry-run --from path/to/new-version
```
Read the list of files it would bring in and the list it would keep. This is your chance to confirm your customizations are in the keep list.
Apply the update. Run it for real and type yes when it shows you the preview.
```
npx pnpm run update -- --from path/to/new-version
```
Reinstall dependencies if the helper tells you the dependency list changed. It prints the exact command.
Let the doctor check your wiring. The helper runs a setup check at the end and tells you if anything needs attention.

Let the Guided Companion Walk You Through It#

If you would rather have a hand held through the whole thing, your download includes a guided companion for Claude Code. Open your project in Claude Code and it can read the setup guide, run the update helper with you one command at a time, explain each step in plain language, and confirm the sensitive ones before you run them. You do not need to be a developer to follow it. This is the same guided experience that walks a first-time buyer through the initial setup, pointed now at an update.

Deploy and Migrate When You Are Ready#

Getting the new code onto your machine is the safe, reversible half. Making it live is the second half, and the helper prints your exact next steps because they depend on what actually changed.

Test somewhere other than production first. Bring the update up against a non-production backend and click through the feed, the classroom, chat, events, and the admin before you touch your live community. A problem found off to the side is an inconvenience. The same problem found live is an incident.
Deploy the backend if it changed. The helper tells you when a release touched your backend and prints the command to push it. Deploying your website does not deploy your backend, so this is its own step.
Deploy your website. Push your updated code and your host rebuilds it, or redeploy by hand from your host's dashboard.
Run any data change last, and only if the release calls for one. Take a fresh export immediately before you run it. A data change runs against real data, so a current backup in hand is not optional.
Remember your mobile apps wrap the web app. A web update reaches them once you push a new app build. See Mobile Apps for iOS and Android.

Skipping a required data change is the most common update mistake. If the app complains about missing or mismatched data right after an update, a data change that did not run is the first thing to check.

Roll Back If You Need To#

You own the source, so a way back is always available.

Code rolls back by returning to the snapshot you took before updating. The helper reminds you to make one, and if your install is a version-controlled folder that snapshot is a single command it prints for you.
Data rolls back by restoring the export you took right before any data change.

If an update goes wrong, restore your pre-update export into a fresh backend, put the prior code back, and cut over. This is exactly why the back-up-first rule exists. It is what makes rollback a real option rather than a wish.

Was this page helpful?