Skip to content

SurgePilot v1.2.3

Choose a tag to compare

View all tags
@github-actions github-actions released this 22 Sep 17:06
· 20 commits to main since this release
v1.2.3
72214f5
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Highlights

  • Adds the first bounded user-local installed-release transition, preserving the existing
    Compose project, volumes, deployment configuration, credentials, Workspace data, artifacts,
    Monitoring data, and the first-Admin system API Catalog document.
  • Keeps release payloads in immutable version directories selected by one small dispatcher.
  • Refuses migration while Runs, initialization, leases, control requests, or report parsing are
    active.
  • Uses the installed psycopg 3 driver when probing databases created by the v1.0.0 and v1.1.0
    deployment configuration.
  • Correctly validates the distinct vX.Y.Z Runtime artifact identity and the preserved historical
    system Catalog identity during upgrade publication.

Install

Install or prepare this exact release, then start it from an interactive terminal:

curl -fsSL https://github.com/latentrun/SurgePilot/releases/download/v1.2.3/install.sh | sh
surgepilot up

Upgrade

Automatic transition is supported from the official v1.0.0 and v1.1.0 releases. Back up the
PostgreSQL, MinIO, and other persistent volumes before upgrading. Stop or finish active Runs and
Load Node initialization work, run the installation command above, and then run surgepilot up.

The transition is forward-only. If target migration or health validation fails, fix the target
problem and retry the same surgepilot up; SurgePilot does not automatically start the older
release or downgrade the database after migration begins. There is no automatic rollback.

Existing Load Nodes retain their previous Runtime version after the control plane is ready. Each
required Load Node must be explicitly reinitialized before new Runs are execution-ready.

Compatibility and breaking changes

  • Supported installed-release upgrade range: v1.0.0 through v1.1.0, within product major 1.
  • A stale local deployment lock fails closed and requires the operator to verify no installer or
    lifecycle command is running before removing that exact lock directory.
  • Manually extracted bundles remain expert-managed and do not use the installed-release transition
    protocol.

Full changelog

See the changes since v1.1.0.

Assets 11
Loading