---
title: "Upgrade your deployment"
description: "Back up your database, bring in a newer release, and deploy it, from the command line or through your Deploy button repository."
---

> Documentation Index
> Fetch the complete documentation index at: https://receipts.nuits.net/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Upgrade your deployment

Use this guide to move your copy of Nuits Receipts to a newer release. A release only tags the code; nothing updates your deployment until you deploy it. Read the [Changelog](/docs/reference/changelog/) first to see what changed, especially under **Breaking changes**.

## Prerequisites

- Wrangler signed in to the account that runs the Worker (`bunx wrangler login`).
- A local clone of the code you deploy from: the repository you cloned for `bun run setup`, or the repository the Deploy button created in your GitHub or GitLab account.
- Bun 1.4.2 or later.

## Back up first

Pending database migrations are applied during the deploy. Take a backup before every upgrade.

1. **Export the database**

   ```sh
   bunx wrangler d1 export <database name> --remote --output backup.sql --config wrangler.production.jsonc
   ```

   Use your D1 database name (`my-nuits-receipts` unless you changed it). With the Deploy button, run it from your clone and leave out `--config` if you have no private config. Keep `backup.sql` somewhere private: it holds your receipt data.
2. **Note a Time Travel point**

   ```sh
   bunx wrangler d1 time-travel info <database name> --config wrangler.production.jsonc
   ```

   This prints the current bookmark, which you can restore to with D1 Time Travel if the upgrade goes wrong. D1 also takes a backup when migrations are applied.

Your original files live in R2 and are not changed by an upgrade.

## Upgrade from the command line

1. **Get the new code**

   Pull the release into your clone, for example `git pull`, or `git checkout v1.2.3` for a specific tag. Your `wrangler.production.jsonc` is gitignored and is not touched.
2. **Install the dependencies**

   ```sh
   bun install --frozen-lockfile
   ```
3. **Check the config**

   ```sh
   bun run deploy -- --dry-run
   ```

   A newer release can add variables or tighten checks. The dry run lists any variable that needs fixing without touching your account.
4. **Deploy**

   ```sh
   bun run deploy
   ```

   The script lists pending migrations, applies them (Wrangler asks you to confirm in an interactive shell), then deploys. If anything fails, the Worker is not deployed.

   If your config uses its own migrations folder or table (an older private install), the script stops and asks for a backup. After taking one, run `bun run deploy -- --apply-migrations`.

## Upgrade a Deploy button copy

The Deploy button created a separate repository in your account, not a fork, so it does not follow new releases by itself. Every push to its production branch builds and deploys through Workers Builds, which runs `bun run deploy`.

1. **Add the original repository as a remote**

   In your clone, once:

   ```sh
   git remote add upstream https://github.com/bapspatil/nuits-receipts.git
   ```
2. **Merge the release**

   ```sh
   git fetch upstream --tags
   git merge v1.2.3
   ```

   Replace `v1.2.3` with the release you want. If Git refuses with "refusing to merge unrelated histories", your copy was created without the original history; add `--allow-unrelated-histories` to the first merge. If `wrangler.jsonc` conflicts, keep your own names, `vars` and routes, and take the release's other changes.
3. **Check, then push**

   ```sh
   bun install --frozen-lockfile
   bun run deploy -- --dry-run
   git push
   ```

   The push starts a build. Follow it in your Worker's **Deployments** or **Builds** page in the Cloudflare dashboard.

:::note
Variables changed only in the Cloudflare dashboard are replaced by `wrangler.jsonc` on every deploy. Keep them in `wrangler.jsonc`, or set them in the app where possible; app settings are stored in the database and survive deploys. Secrets are never removed by a deploy.
:::

## Check it worked

1. The deploy or build log ends without errors, after "Deployed" or the build's success message.
2. Open the app and sign in. The footer shows the new version number.
3. Open **Settings** and check that your values are still there, each marked **Set in the app**, **Set when deployed** or **Built-in default**.

If the build fails at the D1 migrations step with an authentication or permission error, see [Troubleshoot](/docs/how-to/troubleshoot/).

## After upgrading to v2.0.0

v2.0.0 makes Home the archive of every finance document. It brings one new database migration, `0012_archive`, which the deploy applies like any other. It only adds: a column for each file's searchable words, and tables for other documents, tags, stars and notes, saved searches and recently opened files. No existing data is changed.

Backups keep working the same way. `wrangler d1 export` still exports the whole database, which is why search does not use full-text search tables (the export refuses databases that have them).

Files you added before the upgrade can be found by their details (seller, amounts, dates, file name) at once, but not yet by the words inside them. To index them:

1. **Open the search settings**

   Open **Settings**, then **Advanced**, and find **Search**. It says how many older files can be found by their details but not yet by the words inside them.
2. **Index the older files**

   Select **Index older files (N left)**. Each press reads 25 files. Press it again until the section says "Every file can be found by the words inside it."

   Home also reads a few older files on every visit, so the count goes down by itself over time. Pressing the button more than once does no harm: a file is indexed once.

Bank statement PDFs imported before v2.0.0 were not kept, only the CSV they were converted to. Those statements show as a table. Old links to Receipts All (`/receipts?view=all`) now open Home. See [Find any document](/docs/how-to/find-any-document/).

## Related

- [Changelog](/docs/reference/changelog/)
- [Deploy from the command line](/docs/how-to/deploy-from-the-command-line/) for how the deploy script picks its config and resolves the database.
- [Data model](/docs/reference/data-model/) for the D1 tables a migration may change.

Source: https://receipts.nuits.net/docs/how-to/upgrade-your-deployment/index.mdx