# Updating Your Instance > How to bring a new Seedly CRM release into your instance with the guided update helper, review what changed, deploy and migrate safely, and roll back if you need to. You bought Seedly CRM once and you own the source. That means nothing on your build changes unless you bring it in. Updates are something you choose, on your schedule, after you have looked at what is in them. This page is the safe way to bring a new release into your instance, using the guided helper that ships with the product. --- ## How Updates Reach You Your download is a clean copy of the code. It has no connection back to a central repository, so there is nothing to `git pull`. 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: your secrets, your version history, your installed dependencies, and any file you customized. Every download ships with a changelog in its root, and the same release notes, newest first and in plain English, live on the [Changelog](/docs/changelog) page. Read that first to decide whether a release is worth bringing in now. Entries worth applying to an existing install are called out; most releases are safe to skip until you are ready. --- ## Your Data Is Never Touched Your contacts, deals, messages, and settings live in your database, not in these code files. Updating the code cannot change a single row of your data. A code update and a data change are two different things. Most releases are code only. When a release does need a data change (a migration), it says so plainly, and the helper prints the exact command for you to run yourself, after the code is in place, when you are ready. --- ## The Update Helper Your download ships with a guided helper. Run it from your project folder: ```bash 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 it does for you: - **Shows you what is new** by reading the changelog in the download. - **Builds a preview** of exactly which files it would bring in and which it would leave alone, and shows it to you before touching anything. - **Keeps your secrets** (your `.env.local`), your version history, your installed dependencies, and any file you have customized. Your keys are never overwritten. - **Waits for you to type `yes`** before it copies a single file. - **Never deletes anything.** It only lays new code over old code. - **Never deploys, never runs a migration, never touches your database.** It prints those next steps for you to run yourself, when you are ready. - **Runs a setup check at the end** to confirm your instance is still wired up correctly. Two 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 1. **Take a backup.** Export a full snapshot you keep off-platform before you touch anything. See [Backups and Data Ownership](/docs/help/backups). This is the single most important step, and it is the one people skip. 2. **Read what changed.** Skim the [Changelog](/docs/changelog) from your current version forward. Note anything flagged as worth applying and anything that touches a module you rely on. 3. **Download and unzip the new version** somewhere you can find it. 4. **Preview the change** without touching anything: ```bash 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. Confirm your customizations are in the keep list. 5. **Apply the update.** Run it for real and type `yes` when it shows you the preview: ```bash npx pnpm run update -- --from path/to/new-version ``` 6. **Reinstall dependencies** if the helper tells you the dependency list changed. It prints the exact command, and reminds you to commit the updated lockfile. If you would rather be walked through it, open your project in [Claude Code](https://claude.com/claude-code). It can run the helper with you one command at a time, explain each step in plain English, and confirm the sensitive ones before running them. You do not need to be a programmer to follow it. --- ## 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 in a non-production environment first.** Your backend supports a separate development deployment, and your frontend host can build a preview. Bring the update up there, run the setup doctor, and click through the flows the release changed plus a few core ones (sign in, open a contact, send a message, run a workflow) before you touch production. - **Deploy the backend if it changed.** When a release touches your backend, the helper tells you and prints the deploy command. Deploying your frontend does not deploy your backend, so this is its own step. Never let a schema change meet your production data for the first time. Push it to development, confirm it applies cleanly and your data still reads correctly, then promote it. - **Deploy your frontend.** Commit and push your updated code, and your host rebuilds it automatically. - **Run any migration last, and only if the release calls for one.** Take a fresh export immediately before you run it. A migration runs against real data, so a current backup in hand is not optional. Skipping a required migration is the most common update mistake. If the app complains about missing or mismatched data right after an update, a migration that did not run is the first thing to check. --- ## Rolling Back Because you own the source, rolling back is straightforward. - **Code.** Return to the snapshot the helper reminded you to take before updating, or redeploy the previous commit. Your frontend host also keeps previous deployments you can promote back instantly. - **Data.** If a migration changed your data and you need to undo it, restore from the snapshot you took before the update. This is why the pre-update export is not optional. See [Backups and Data Ownership](/docs/help/backups). Roll back on your own build, on your own timeline. Nobody can force a change onto you and nobody can stop you from reverting one. --- ## You Decide When to Update This is the whole point of owning the source. There is no forced upgrade, no end-of-life on a version you are happy with, and no vendor deciding your build changes overnight. You bring in a release when it earns its place on your build, after you have read it, backed up, tested it, and confirmed you can roll it back. That is control, and it is yours. --- ## Related - [Changelog](/docs/changelog) - what shipped in each release, newest first - [Backups and Data Ownership](/docs/help/backups) - export before every update, restore if you must - [Setup and Deployment](/docs/setup) - how your instance was stood up in the first place - [Architecture](/docs/architecture) - the stack, deployments, and how migrations apply --- Source: https://seedlycrm.com/docs/help/updating