Upgrade Oore

For a Ready Complete or Control plane installation, update the current release stream in place:

oore update --check
oore update

Oore drains active runner work, creates a backup, restarts managed services, and verifies the new release. It restores the prior release when verification fails.

Use oore-web update on a separate Web node.

oore install does not replace live profile components across release streams. Use the preserve-data procedure when you change the stream or profile.

This guided update procedure supports macOS only. Published Linux web archives do not provide a guided Web node lifecycle.

Upgrade from v0.1.41

Start the v0.1.42 bootstrap with the same install root, channel, and repository.

The bootstrap detects an exact v0.1.41 installation before it publishes the new CLI.

It downloads and verifies the v0.1.42 candidate first. That candidate then shows a preserve-data removal plan.

Approve oore uninstall --legacy-v0-1-41 when the bootstrap offers it.

Oore verifies the old payload and services before any removal. It requests administrator access for protected launchd definitions.

The removal preserves the database, configuration, logs, runner registration, FVM files, and downloaded toolchains.

The bootstrap then installs the v0.1.42 CLI. Run oore install and select the matching new profile.

Use these mappings:

v0.1.41 mode	v0.1.42 profile
`all`	`complete`
`frontend`	`web-node`

The old backend mode included both a control plane and a runner. v0.1.42 has no identical profile.

Do not guess a replacement profile for backend. Record the required topology before this upgrade.

For a non-interactive bootstrap, activate administrator access first with sudo -v.

Then set OORE_LEGACY_UPGRADE=true to approve the displayed legacy plan.

Do not use --purge. The legacy recovery path rejects it.

What you need

Record the existing profile, release channel, install root, and release repository.
For Complete or Control plane, create a verified Oore backup.
Read the target release notes.
Keep enough free space for downloads and rollback files.

1. Check for a release

oore update --check

This command verifies the signed channel index and checksum manifest. It does not download or execute a release candidate.

To inspect another channel, add --channel stable, --channel beta, or --channel alpha.

2. Remove the current components

Run the normal uninstall before you replace the bootstrap CLI:

oore uninstall

Do not add --purge. Normal uninstall preserves Oore data.

3. Install the next bootstrap CLI

Use the same channel, install root, and release repository as the current installation.

For the default stable installation, run:

curl -fsSL https://oore.build/install | bash

For a custom installation, pass its recorded values:

oore_install_root=/Users/example/.oore-beta
oore_channel=beta
oore_repository=oore-ci/oore.build

curl -fsSL https://oore.build/install | \
  env OORE_CHANNEL="$oore_channel" \
      OORE_INSTALL_ROOT="$oore_install_root" \
      OORE_GITHUB_REPO="$oore_repository" \
  bash

The bootstrap verifies signed release metadata, then verifies the new CLI with SHA-256.

If publication fails, the bootstrap restores the prior files.

4. Install the same profile

Use the same profile that the installation already records:

/Users/example/.oore-beta/bin/oore install --profile complete

Valid profiles are complete, control-plane, runner, web-node, and cli-only.

Replace the example path and complete with the recorded installation values.

Do not select another profile during this release change.

An interactive install continues through setup and service repair.

After a non-interactive install, run setup with the existing values:

chmod 600 ./oore-setup.yaml
sudo -v
/Users/example/.oore-beta/bin/oore setup --config ./oore-setup.yaml

CLI only setup does not need sudo -v.

Verify the result

/Users/example/.oore-beta/bin/oore version

Replace the example path with the recorded install root. Verify that the version matches the target release.

Setup must end with <Profile> setup is ready. Oore prints this message only after final service verification.

Use oore status to inspect the connected control plane. For a remote role, pass --daemon-url <URL>.

For a Runner or Complete profile, run a small build from an approved repository.

Failure behavior

The bootstrap and component installer bind downloads to the signed release manifest before publication.

If component publication fails, Oore restores the previous component files when safe.

If installation fails after normal uninstall, the preserved Oore data remains. Correct the error, then repeat the bootstrap and profile installation.

Do not use hidden staged-archive or supervisor options.

For a source-built installation, use its deployment procedure. This release change flow covers release installations only.

Next step

Monitor Oore through the next normal build.

On this page