Upgrades
Move to a new Pinwren release — pull the image, restart, and let the migrations run.
Pinwren follows semantic versioning. Before 1.0, a minor release (0.1 → 0.2) may
contain breaking changes; patch releases (0.1.0 → 0.1.1) never do. Read the changelog or the
GitHub releases before you upgrade.
Security fixes land on the latest minor release only, so stay on it.
Upgrade
Point at the new version
PINWREN_IMAGE=ghcr.io/krithik-m-codes/pinwren:0.2.0If you build from source instead, git pull the release tag.
Pull and restart
docker compose -f docker/compose.yml --env-file docker/.env pull pinwren
docker compose -f docker/compose.yml --env-file docker/.env up -dCheck the logs
docker compose -f docker/compose.yml logs -f pinwren
# [pinwren] database migrations appliedHow migrations run
On every start, before the first request, the server applies any pending database migrations
(apps/web/src/instrumentation-node.ts). They run under a Postgres advisory lock, so several replicas or
cluster workers starting at once never race — one applies them, the others wait. The configuration is
validated at the same moment, so a bad variable stops the start with a clear message.
Set PINWREN_SKIP_MIGRATIONS=true to skip this step, for example when you run migrations from a separate
release job. You are then responsible for running them before the new version serves traffic.
No downgrades
Migrations only move forward, and the server does not check whether the database was migrated by a newer version. Running an older image against a newer schema is not supported. To roll back, restore the backup you took before the upgrade.
Knowing when to upgrade
Instance admins see Update available in the dashboard when a newer release exists. A daily job compares
PINWREN_VERSION with the latest release of PINWREN_UPDATE_REPO on GitHub. Turn it off in Settings ›
Security or with PINWREN_UPDATE_CHECK=false (which also locks the switch); it is off on its own while any
project uses privacy mode, and it makes no other outbound call.
The sidebar badge next to the logo shows your edition (Community Edition), with a dot while an update is
waiting. Instance admins also get a thin, dismissible strip with the release notes and the update command; it
returns for the next release. Rarely (after two weeks of use, then at most monthly, with "Don't ask again") they
see a card asking to star the GitHub repository or sponsor the project. Set PINWREN_NUDGES=false to hide the
strip and the card for everyone; Pinwren Cloud never shows them. Dismissals are remembered in your account.
What the badge, strip and card do
| Piece | Who sees it | Behaviour |
|---|---|---|
| Edition badge | Everyone | Community Edition or Enterprise Edition next to the logo; Cloud shows none. A dot means an update is waiting. |
| Update strip | Instance admins | "Pinwren X is out (you are on Y)", the update command and Release notes. Dismiss hides it for that release only. |
| Sidebar update link | Instance admins | Appears while an update is waiting. |
| Support card | Instance admins, Community only | A thin strip (never a modal) asking you to star or sponsor, after 14 days of use. Dismissing snoozes it 30 days; Star on GitHub or Sponsor 90 days; Don't ask again ends it. |
Two switches control this. PINWREN_UPDATE_CHECK=false stops the daily release lookup (no strip, no badge dot); it
sends no instance or user data, and offline or air-gapped installs just keep the last result. PINWREN_NUDGES=false
hides the update strip, the sidebar link and the support card for everyone; the edition badge stays. In Pinwren
Cloud nudges are always off. Dismissals live in the browser (localStorage), so another browser asks again.
You can also watch the repository's releases on GitHub (Watch › Custom › Releases).