PORTLANEDocs

Updating Portlane

Installing from scratch and upgrading are the same one-command flow — your data and configuration are preserved automatically, with a clean rollback path.

Upgrading a Portlane instance is the same gesture as installing it: download the new bundle and run install.sh again. There is no migration window, no data to move by hand, and no configuration to rebuild. The installer detects whether this is a first install or an update and does the right thing.

How an update runs

# 1. Download the new bundle from the client portal and unzip it
#    NEXT TO the previous one (sibling folders: portlane-core-0.0.1/, -0.0.2/, …)
unzip portlane-core-0.0.2.zip && cd portlane-core-0.0.2

# 2. Verify integrity
sha256sum -c checksums.sha256

# 3. Run the same installer — it starts the new version in place
./install.sh

That is the whole procedure. The same command that installed the platform upgrades it.

What is preserved for you

Nothing to migrate, nothing to reconfigure:

  • Your data stays put. Database volumes are tied to a fixed project identity, so they are never recreated across versions — history, licenses, and logs carry over untouched.
  • Your configuration is carried forward. Secrets are never shipped inside a bundle; the installer picks up the configuration from your previous install automatically and never overwrites an existing one.
  • No accidental downgrades. A pre-flight check refuses any bundle older than the schema already on the instance.
  • Only what changed restarts. Engines whose image is unchanged keep running; the update is close to zero-downtime.

Rollback

If anything looks wrong after an upgrade, return to the previous version in one step:

./deploy/rollback.sh

Because schema changes are additive and idempotent, the previous version tolerates what the newer one added. The exact image versions of each release are pinned, so a rollback restores precisely the prior state.

Why this matters

Portlane runs on your infrastructure, but operating it should not feel like a project. Deployments are transparent by design:

  • One command, from a bare server to running — the installer sets up Docker if needed and pulls signed, digest-pinned images. Nothing to compile.
  • Signed and reproducible — every image is signed with an SBOM and pinned by digest; the bundle ships with checksums and a signature, so you verify exactly what you run.
  • Air-gapped ready — an offline bundle carries every image, so the whole platform installs with no outbound network at all.

Your team ships the update and moves on — no vendor cloud in the loop, no infrastructure choreography.

On this page