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.
Loading the guide...
Help us make the guides more useful.
2 helpful · 0 not helpful
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.
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 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 contacts, deals, messages, and settings live in your database, not in the downloaded code files. The update helper copies code and does not run a data migration. A later deployment or migration is a separate step and can affect stored data, which is why this guide starts with a backup. The release notes identify when a migration is needed and the helper prints the command to run after the code is in place.
Your download ships with a guided helper. Run it from your project folder:
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:
.env.local), your version history, your installed dependencies, and any file you have customized. Your keys are never overwritten.yes before it copies a single file.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.Take a backup. Export a full snapshot you keep off-platform before you touch anything. See Backups and Data Ownership. This is the single most important step, and it is the one people skip.
Read what changed. Skim the Changelog from your current version forward. Note anything flagged as worth applying and anything that touches a module you rely on.
Download and unzip the new version somewhere you can find it.
Preview the change without touching anything:
Read the list of files it would bring in and the list it would keep. Confirm your customizations are in the keep list.
Apply the update. Run it for real and type yes when it shows you the preview:
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. 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.
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.
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.
Most skipped migrations do not break anything visibly. The app keeps working and simply behaves as though the older data does not exist, so the damage shows up later as figures that look wrong for no obvious reason rather than as an error you can chase.
Three habits protect you:
CHANGELOG.md inside your download opens with either an action-required box or an explicit "nothing to run" box. There is never neither, so if you cannot find one, you are reading the wrong section.A release that restates past figures, or rewrites a stored value across your records, will say so and will offer a dry run. Run the dry run and read its summary before the real thing.
The helper never deletes anything, by design - so a release that removes a file leaves the old copy on your instance. In almost every case that is harmless: the removed file is no longer imported by anything, so it just sits there and never runs. Occasionally a release calls out a file it wants you to delete yourself, and those are worth doing.
The 5.7.0 release removed five email-composer files that had been replaced but never deleted. Nothing in the product imports them, but one of them displays email previews without the sanitiser protection every other preview uses, so leaving it on disk after 5.7.0 is worth cleaning up:
apps/web/app/(dashboard)/location/[locationId]/campaigns/[id]/_components/email-composer.tsxapps/web/app/(dashboard)/location/[locationId]/campaigns/[id]/_components/broadcast-editor.tsxapps/web/app/(dashboard)/location/[locationId]/campaigns/[id]/_components/sequence-editor.tsxapps/web/app/(dashboard)/location/[locationId]/campaigns/templates/_components/email-block-config.tsxapps/web/app/(dashboard)/location/[locationId]/campaigns/templates/_components/template-editor.tsxThere is a similarly named template-editor.tsx under payments/templates/. That one is in use - do not delete it. The five above are safe to remove after your 5.7.0 update lands.
Because you own the source, rolling back is straightforward.
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.
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.