Updates

#Updates

Your instance checks itself against EmuView's tagged releases and tells you when a newer one exists. What happens when you act on that depends on your update channel.

#The version card

The System dashboard shows the running version (with its build commit) and, when a newer release is published, an Update available badge linking to the release notes. The check runs server-side and is cached for an hour; the refresh button forces a fresh look.

Only tagged releases count. Development activity on main never nags your instance — a new version exists only when one is deliberately released.

If the card says update checks not configured, set a GITHUB_TOKEN secret on the gateway worker — the badge needs it to read releases.

#Update channels

Choose how your instance deploys in Settings → System → Update Channel:

Channel	The card shows	What "Update now" does
Manual (default)	The exact commands to run	Nothing — you stay in full control
Workers Builds	An Update now button	Syncs your GitHub fork with upstream; your connected Cloudflare Workers Builds redeploys automatically
GitHub Actions	An Update now button	Dispatches your fork's deploy workflow with the new release tag, deploying exactly that version

The design principle behind all three: the app never deploys itself. The button only nudges git — a fork sync or a workflow dispatch — and your own pipeline does the deploying. That's why using the button never conflicts with deploying by hand later.

The git channels need two settings besides the channel itself: the Update Repository (your fork, as owner/repo) and the Update Branch (usually main), plus a GITHUB_TOKEN with write access to that fork. Setup details, including the one-time fork configuration, are in the upgrade guide.

#Triggering and results

The Update button requires the system/settings:update permission and every press is audit-logged. The card reports exactly what happened:

• Fork synced — Workers Builds will redeploy shortly / deploy workflow dispatched
• Already up to date — your fork matches upstream
• Merge conflict — your fork has local changes that clash with upstream; resolve on GitHub, then try again
• Configuration problems, with what to fix

#Before you update

An update can include database migrations, and those — unlike code — can't be rolled back. Make it a habit:

1. Read the release notes the badge links to
2. Back up before updating
3. Know the rollback path for the code side

#What you learned

• Instances compare themselves against tagged releases only — main never triggers anything
• The update channel decides whether you get commands or a real one-click button
• The button nudges git; your own pipeline deploys — manual deploys stay possible on every channel
• Back up first: code rolls back, migrations don't