Recover from a problem

Applies to Workletto 1.x.

Most problems after an update are fixed by going back to the previous version, without losing anything. Restoring a backup is for the rarer cases where the data itself is affected. This page says which to use. The commands for each host are in your copy’s README.md, under Backups and recovery.

Before every update

Download a backup: Manage → Security & data → Download backup. See Back up and restore. The Update app workflow asks you to confirm you have one before it runs.

If you can, also keep a copy of the database itself. Render’s paid databases keep their own and can go back to an earlier point in time; check your plan. The README shows the one command for Docker Compose.

Something looks wrong after an update

Go back to the previous version of the code:

• On Render, open your web service and roll it back to its previous deploy.
• With Docker Compose, the README gives the two commands.

Nothing is lost: everything entered since the update stays. Updates within version 1 only add to the database, so the previous version runs on it as before. Don’t use GitHub’s Revert button on the update’s pull request: later updates would then leave out what it changed.

The app won’t start after an update

When an update changes the database and that change fails, the app doesn’t start. On Render the update’s deploy fails and the previous version keeps running for now, but it can’t restart until this is fixed. With Docker Compose the app keeps restarting. Your host’s log shows the change that failed, and later starts say P3009.

Choose one way back:

1. Restore the database copy you took before the update, then go back to the previous version. The README shows how, and says to stop the app first.
2. Or install a fresh copy and restore your backup into it. This needs no tools: deploy the app again as when you first installed it, with the same BETTER_AUTH_SECRET, and restore your backup from its setup screen. Then point your address at the new copy. See below.

Someone comfortable with a terminal can instead mark the failed change as undone. The README has the command and says when that’s safe.

Whichever you choose, keep the error from the log: it shows a developer or an AI coding assistant what went wrong.

Your host fails, or you’re moving

1. Install the app on the new host, with the same BETTER_AUTH_SECRET as before. Your email password, Stripe key and single sign-on secret are stored encrypted with it. With a different one, the app asks for them again, and nothing else is affected.
2. On the new install’s setup screen, click Restoring from another install? Restore a backup and restore your backup. See Back up and restore.
3. If the address changed, set BETTER_AUTH_URL to it (see Use your own address). If you use single sign-on, add the new redirect address at your provider; Manage → Settings shows it. If you take payments online, Manage → Payments says Stripe’s notifications go to the old address and lets you move them.
4. Everyone signs in again with their usual password.

Older and newer versions

A backup restores on the same version of the app or a newer one: when it starts, the app adds what the newer version changed. A backup from a newer version is refused by an older install: update the install first, then restore.

What a backup can’t bring back

Anything entered after the backup was made. Back up before every update, and regularly in between.