Oktapod Docs

Updates

Check for and install Oktapod updates from chat or the terminal, with an automatic backup and rollback.

Oktapod can update itself. Every update is backed up first and checked afterwards, and a failed update rolls back on its own.

From chat

Ask:

Is there an Oktapod update?

Checking never changes anything. If a newer version exists, Oktapod asks whether to install it. Your yes, or /update apply, is the confirmation; there is no second approval. Oktapod then:

  1. makes a full backup;
  2. installs the new release;
  3. restarts the service;
  4. runs its health and readiness checks; and
  5. reports the result in the same chat.

If anything fails, it restores the previous version and backup, restarts, and tells you what happened. If you are already on the latest version and healthy, it only confirms that; it does not rebuild or restart.

/update check is the same read-only check as a command. Updating from chat works in one-to-one chats, not group chats.

From the terminal

oktapod update --check
oktapod update

To install a specific release, pass the tag that --check reports. Some install types, such as prebuilt binary installs, require it:

oktapod update --tag <release-tag>

Failed updates exit with status 1, including updater run and automatic updater tick installs. With --json, the updater still prints its failure report to stdout so scripts can inspect the outcome and error. Restoring the previous version does not turn a failed install into success.

If an update fails, the error names the backup it created. To restore it by hand:

oktapod restore --input <backup-path> --verify
oktapod checkup

Automatic checks

On macOS and Linux, the installer schedules a check every six hours. Manage it with:

oktapod updater status
oktapod updater disable
oktapod updater enable --interval-hours 6

Checks only look. Installing stays your decision unless you turn on automatic installs with oktapod updater enable --auto-apply. Single-executable builds need a verified binary feed for automatic installs. Operator-managed private feeds require their release credential; public binary feeds carry no credential.

Stable and beta

Installs follow the stable channel by default. To follow beta releases:

oktapod updater configure --channel prerelease

Installing with ./scripts/install.sh --channel beta sets this for you.

Managed hosts and the private release feed

An operator-managed host can update from Oktapod's authenticated private release feed instead of GitHub. Oktapod verifies the download's origin, size, digest, and contents before it stops the running service, and restores the previous version if anything fails. Automatic installs of the single-executable build also support a verified public binary feed, described below.

Public binary feeds

A public binary feed uses oktapod.public_binary_release_feed.v1. It includes only executable archives, native sidecar manifests, and the verified release gate report. It contains no source archive or transfer bundle. Downloads stay on the feed's HTTPS origin, and the updater checks their hashes, sizes, commit, and release proof before stopping the installed service. Failed installs use the same backup and rollback transaction as private updates.

Configure a public feed only after its operator publishes the verified files:

oktapod updater configure --release-source https://your-release-host/public/v1/releases/latest

This transport needs neither a GitHub login nor a release token. Preparing its files does not publish them or turn on automatic installs. The /public/v1/releases/ path selects anonymous discovery even when the host already has a private release token. This path accepts only public binary catalogs and refuses redirects.

If a host cannot reach the release source at all, move a verified release bundle from a trusted machine and follow Releasing.