Updates and releases
How Palisade updates itself, how releases are built and signed, and what each release contains.
Palisade updates itself. Each update is checked against the project's signing key before it is installed.
Self-update
- Installed apps check for updates automatically.
- An update is installed only if its signature matches the project's signing key.
- A failed update check never blocks startup.
What a release contains
Each installable release includes these assets on GitHub:
| Asset | Who it is for |
|---|---|
| Signed updater archive | Existing installs, through self-update. |
| Updater signature | Used to check the archive before install. |
| Notarized universal DMG, model included | First installs. Supports Apple Silicon and Intel Macs running macOS 11 or later. |
Get the latest DMG from the releases page.
How a release is built
- A maintainer pushes a
vX.Y.Ztag. - The tag must match the version in
package.json,src-tauri/tauri.conf.json, andsrc-tauri/Cargo.toml. - The workflow runs its checks.
- It waits for a reviewer to approve it.
- Only the approved job can read release credentials and publish.
The workflow builds the pinned llama.cpp sidecar from source for Apple Silicon (Metal) and Intel (CPU only).
It combines them into one universal binary.
It verifies the model checksum before packaging.
After publication, the update service serves the new release to installed apps. A failed or unapproved workflow cannot change what installed apps receive.
Local builds
Building locally never publishes an update.
./package.sh builds and, unless you pass --no-install, installs the app on your Mac.
It does not need or read updater credentials.