Skip to content

rai self-upgrade

Update the rai package and the project in one command. Runs the package update (self-update) before the project update (upgrade) — reversing the order would sync the project against a stale package.

Prints a restart notice when the package changed: the MCP server keeps the previous binary in memory even after rai --version reports the new one.

Usage

rai self-upgrade [OPTIONS]

Options

Flag Description
--version Specific version to upgrade to (default: latest published)
--dry-run Preview package + project changes without writing anything

Examples

# Update everything to latest
rai self-upgrade

# Preview what would change
rai self-upgrade --dry-run

# Pin to a specific version
rai self-upgrade --version 3.1.247

Rollback and Recovery

Rollback is machine-level, not per-project. Understanding why helps you plan upgrades in multi-project environments.

Why rollback is machine-level

Layer Scope Rollback granularity
Package (rai self-update) Single binary shared across all projects Machine — one binary serves every project
Database (~/.rai/raise.db) One global DB, per-project data isolated via project_id Machine — schema migrations are forward-only and run on first open
Project (rai upgrade) Skills, config, .raise/ per checkout Per-project — already isolated

Rolling back the binary to fix one project's post-upgrade issue reverts it for all projects. The database migration compounds this: an older binary cannot open a migrated schema, so a binary rollback also requires restoring the DB backup — losing data recorded after the upgrade across every project.

Before upgrading

cp ~/.rai/raise.db ~/.rai/raise.db.backup-$(date +%Y%m%d)
rai db export

rai db export writes per-table JSONL files that survive a schema change. The raw .db copy is faster to restore but only works with the schema version that wrote it.

If you need to roll back

# 1. Restore the binary
curl -fsSL https://github.com/humansys/raise/releases/latest/download/install.sh \
  | bash -s -- --version <previous-version>

# 2. Restore the database (required — older binary cannot open migrated schema)
cp ~/.rai/raise.db.backup-YYYYMMDD ~/.rai/raise.db

# 3. Re-upgrade projects that were fine (optional)
cd /path/to/good-project && rai upgrade

Data recorded after the upgrade is lost in the DB restore. This affects all projects, not just the problematic one.

Per-project mitigation

The project layer (rai upgrade) is already per-project. If only one project has issues after upgrading:

  1. Re-run rai upgrade in the affected project — idempotent, safe to retry.
  2. Use --dry-run first in multi-project setups: rai self-upgrade --dry-run previews changes before committing.
  3. Upgrade projects incrementally — run rai self-upgrade from one project, verify, then rai upgrade in each remaining checkout.

See Also