Updates

Login → Admin → Updates. One screen lists everything with a pending update — TigerCore and each installed module — with checkboxes and an Update / Update All button. Click, and it self-installs. No shell, no Composer, no FTP.

What you see

Each stale item shows its current version → the latest, and a checkbox. Nothing pending? The screen says so — you're current. Check again re-runs detection (versions are cached a few hours, so this forces a fresh look at GitHub/Packagist).

Applying an update

Select what you want and click Update (or Update All). A live step log streams as it works — resolve → download → verify → apply → done — so if anything fails, the failing step names itself.

• Modules update the real no-shell way: the release is downloaded, extracted, migrated, and its assets republished.
• TigerCore updates by atomically swapping a pre-resolved release bundle into place — the dependency graph was resolved for you in CI, so your host only unpacks and swaps. During the swap the site shows a brief "Updating…" page; on any health-check failure it rolls back to the previous version automatically. If your host can't self-swap (a read-only vendor/), the screen tells you and points at the Composer command instead.

Update history

Below the list, Update history keeps a durable record of every run — what was updated, the version change, the outcome (success / failed / rolled back / advisory), and the full step log (expand any row). So "what did we update, and what broke?" is answerable long after the run.

Who can do this

Updating the platform and modules is a superadmin action. Everyone else is denied by default.

Good to know

• Updates are deliberate — nothing auto-installs. Your versions change when you click.
• A module or core stays pinned to its installed version until you choose to move it — no surprise changes on a live site.