Upgrading QuoteNode

QuoteNode checks for new releases automatically. When a newer version is available, the admin panel shows a notification with the release label and a link to release notes.

Upgrading to PostgreSQL 18

The Compose files already use postgres:18-alpine, so fresh installs need nothing. If you ran an earlier alpha on PostgreSQL 16, migrate the data once — a PostgreSQL 18 server cannot start on an older data directory, and the app never rewrites it automatically. Follow the dedicated, data-safe procedure: Migrating data to PostgreSQL 18 (host-CLI and UI-only paths, per platform).

How version checks work

The frontend fetches https://quotenode.dev/releases/latest.json on admin login. This is a read-only, unauthenticated GET request. No data from your instance is sent. The check can be disabled:

VITE_RELEASE_CHECK_ENABLED=false

You can also override the manifest URL:

VITE_RELEASE_MANIFEST_URL=https://your-mirror.example.com/releases/latest.json

If the manifest is unreachable, the check fails silently and the admin panel works normally.

Pre-upgrade checklist

Before upgrading:

1. Note the current version visible in Admin > License or in the release notification.
2. Back up .env — this file contains secrets that cannot be regenerated (especially DB_ENCRYPTION_KEY).
3. Run a database backup:

docker compose exec postgres pg_dump -U quotenode quotenode > backup-before-upgrade.sql

4. If automated backups are enabled (BACKUP_ENABLED=true), verify a recent backup exists in the backup volume.

Upgrade procedure

For Docker Compose deployments (Ubuntu VPS, LAN Linux, Coolify manual):

docker compose pull
docker compose up -d

This pulls the latest images and recreates only the containers whose images changed. Database migrations run automatically on backend startup.

For Coolify with auto-deploy enabled, pushing to the configured branch triggers the upgrade automatically.

Post-upgrade verification

After the containers are running:

1. Open /health — should return UP.
2. Log in and check Admin > License for the new version number.
3. Create a test offer and generate a PDF to verify the pipeline works.
4. Open a public link to verify frontend routing.
5. If SMTP is configured, verify a test notification email is sent.

Rolling back

If the upgrade causes problems:

1. Do not run docker compose down -v — this deletes all data including the database.
2. Stop the services:

docker compose down

3. Edit docker-compose.yml (or .env) to pin the previous image tags:

services:
  backend:
    image: ghcr.io/lesisty7/quotenode/quotenode-api:v0.9.0-alpha
  frontend:
    image: ghcr.io/lesisty7/quotenode/quotenode-frontend:v0.9.0-alpha

4. Start again:

docker compose up -d

If the new version included irreversible database migrations, rolling back the images alone may not be enough. In that case, restore the database from your pre-upgrade backup:

docker compose down
docker compose up -d postgres
docker compose exec -T postgres psql -U quotenode quotenode < backup-before-upgrade.sql
docker compose up -d

Pinning image tags

The installation guides use latest tags for simplicity. For production deployments, pin explicit version tags to control when upgrades happen:

services:
  backend:
    image: ghcr.io/lesisty7/quotenode/quotenode-api:v0.9.0-beta
  frontend:
    image: ghcr.io/lesisty7/quotenode/quotenode-frontend:v0.9.0-beta

Then upgrade by changing the tag and running docker compose up -d.

Version format

QuoteNode uses semantic versioning with a channel suffix:

• v0.9.0-alpha — early development
• v0.9.0-beta — public beta
• v0.9.0-rc — release candidate
• v0.9.0 — stable release

The release manifest includes version, channel, label, and imageTags so the frontend can compare versions accurately.