Operations and updates

Update Chetty on a server

Install the latest release your licence covers, in one command, and know what Chetty checks before it switches versions.

Before you start

An instance installed from a licensed release, with root or sudo on the host.
A valid licence, and a licence server that the host can reach.
A recent backup of the database and the instance folder. See Back up before an update.

Run the update

Run the update:
```
elowen update
```
Wait for the services to restart. Chetty briefly stops them, applies the new release and checks that it starts.
Confirm the new version with elowen status, then open the Web UI and send a message.

You can also start the same update from the web app. See Follow an update in the web app.

What the update does

Chetty asks the licence server for the latest release your licence covers and verifies the download by size and checksum. The installer then runs npm ci against the release's reviewed production lock, with native build scripts enabled.

It switches the managed release link atomically, refreshes the root-owned files and restarts the services. If the boot checks fail, the recovery journal restores the previous release. After a successful run, only the current and the previous release stay on disk.

When the install location is not writable by the service user, the update runs its install step as root through a sudoers line pinned to that exact command. The licence token travels on standard input rather than as an argument.

After migrating from an older installation, re-run sudo elowen install once so the new sudoers line is written. Without it, updates ask for an operator password.

A core update is not reversed just because the local database has no approved resource policy: reconciliation reports the policy as operator-controlled and leaves the database settings unchanged. Drift in a policy that was already approved still fails the update.

If the update is refused

The licence server refuses the check. The update fails and names the server's reason, such as a revoked licence, instead of reporting that everything is up to date.
The local licence has expired. The update stops until you renew it. See Licence and activation.
The licence server cannot be reached. No core release is installed and the update says so. The repair of drifted root-owned files still runs.
The instance still has an older update journal. Chetty only accepts the current journal format. Plan a stopped window and let an operator finish recovery with the older updater first; do not force an automatic upgrade.
The installation is a source checkout. It skips the core release but can still update publisher plugins. Update the core code from git, rebuild, then run sudo elowen privileged refresh. See Build from a source checkout.

While an update runs, changes to a plugin it touches are refused until the run finishes. A request that arrives just before a run ends is not lost: the queue watcher, provisioned by install or by sudo elowen privileged refresh, starts another run.

Automatic updates

Automatic updates are optional. Where supported, an administrator enables them in Settings → System. The update timer only runs when that switch is on.

Recover an interrupted update

If a killed process left an update unfinished, finish or reverse it with:

elowen update --recover

This command does not require a healthy running daemon. Depending on the update journal, it finishes or rolls back the transaction and may stop or start the daemon, web and plugin services. Preserve the update files until the operation ends.

Continue with Production & Updates, Follow an update in the web app and Back up before an update.