Aerini Docs

Appearance

Updating ​

This page covers three separate things: checking for and installing a new desktop release, updating a self-hosted aerini-server deployment, and what happens when a workflow file's schema version doesn't match the app or server opening it. For why the desktop check works the way it does instead of updating automatically, see Security §The update check exception.

Desktop app ​

Aerini never checks for updates on its own. Open Settings, find Updates under About, and click Check for Updates. There's no startup check, no background poller, and no scheduled interval; it only runs when you click the button.

The check asks GitHub's Releases API for the latest tagged release and compares it to your installed version. One of two things happens:

  • You're up to date. The status line shows your current version and nothing else happens.
  • A newer version exists. The status line shows the new version number next to a View release link, which opens that release's page on GitHub in your browser.

View release is as far as the button goes. Aerini doesn't download or install anything itself, there's no auto-updater built into the app. Getting the new version means installing it the same way you installed Aerini the first time: download the file for your OS from that release page and run it, the same steps as Installation §Download the installer. Installing over an existing copy doesn't touch your workflows, credentials, or settings; those live in a separate per-OS data folder that the app bundle itself never touches (see Installation §Uninstalling for exactly where).

NOTE

New releases are published as GitHub draft releases before a maintainer manually publishes them. If a version was just tagged, Check for Updates may not show it yet; GitHub's "latest release" API only returns published releases, not drafts.

Server (aerini-server) ​

As of Aerini 0.4.0, no prebuilt aerini-server binary is published anywhere, not on the Releases page or otherwise; that page only carries desktop installers. There's nothing to download for an update either, so the update path depends on how you're running the server. Server Deployment §Getting the aerini-server binary covers this same gap for a first install; this section covers keeping an existing deployment current.

Official Docker image ​

The repository's own Dockerfile and docker-compose.yml aren't published to any container registry. docker compose build builds the image from the source tree already on your disk, so updating means pulling that source and rebuilding:

bash
git pull
docker compose up -d --build

This image's build stage copies your source into the image with COPY, so a git pull that changes any tracked file invalidates the layers built from it, and the rebuild picks up the new code correctly. No --no-cache needed here. The named data volume isn't touched by a rebuild, so your workflows and run history persist across the update.

Bare metal (Linux, built from source) ​

bash
git pull
sudo apt install -y libdbus-1-dev   # already present if you built it before
cargo build --release -p aerini-server

Then replace the running binary and restart:

  • serve mode installed via install.sh: copy the new binary over ~/.aerini-server/<workflow>/aerini-server, then restart with systemctl --user restart aerini-<workflow>, the service name install.sh created for you.
  • api mode, or anything started by hand: stop the running process, replace the binary at whatever path you launch it from, start it again. There's no generated service file for api mode; whatever you used to keep it running (a systemd unit you wrote yourself, a process supervisor) is what you restart.

The desktop's "Export for Server → Docker" package ​

The package generated by Export → Export for Server → Docker builds differently from the official image above: it clones the Aerini repository inside the Docker build itself (git clone --branch $AERINI_REF, defaulting to main), rather than building from source already on disk. That distinction matters for updates specifically. Docker caches that clone step by the Dockerfile instruction's own text, not by what the remote branch currently holds, so re-running docker compose build alone can silently reuse the old cached layer and rebuild the same old code even though main has moved on. Force a fresh clone with:

bash
docker compose build --no-cache
docker compose up -d

or bump --build-arg AERINI_REF=v<newer-version> to a specific tag each time, which also busts the cache since the build argument itself changed. Either way restart afterward; the mounted aerini-server.json and the data volume are unaffected.

Opening older or newer workflow files ​

Every .aerini file, and every workflow saved in Aerini's own database, carries a schema_version field. Whichever app or server loads that workflow checks the field before anything else runs:

SituationWhat happens
File's version matches what this build understandsLoads normally, nothing extra happens
File's version is older, and this build has a migration path for itUpgrades the file's JSON automatically on load, no action needed from you
File's version is older, but no migration path reaches this build's versionLoad fails with an error naming both versions
File's version is newer than what this build understandsLoad fails; the error tells you to upgrade Aerini
File has no schema_version field at all (saved before the field existed)Treated as the oldest known version and loads normally

As of Aerini 0.4.0 the workflow file format hasn't changed since it was introduced: schema_version is "1.0" everywhere, and no migrations are registered yet. Every file loads as a same-version no-op today. The table above describes the mechanism that will run the moment that changes, not a backlog of migrations already waiting to fire. A full version history, once the format has one worth documenting, will live in schema-migrations.md.

There's no downgrade path either way: opening a workflow saved by a newer Aerini in an older one always fails with a message telling you to upgrade, never a partial or best-effort load.

What's next ​