Updating Ballast

Check the version in the app title and System. Download names include the exact version, for example ballast-0.4.0-beta.zip. Public releases and invited beta releases use separate channels; beta eligibility is checked by the server.

Invited beta downloads and the complete version history are at https://ballastdigital.xyz/beta and https://ballastdigital.xyz/releases/. Version 0.4.0-beta remains an invited test release; a wider public launch is deferred. The online release report identifies the published archive hash.

Signed updates in 0.4.0 and later

When an eligible newer release is available, the app offers its version and change summary. Choose Update now or Update later. The System update button remains available after postponing. Read the notes before applying a change to a running trading application.

The app verifies the manifest against its pinned publisher key, checks the archive and every managed file, rejects downgrades and unsafe archive members, and prepares pinned dependencies before stopping the engine. An unsigned release or unavailable verification fails closed. The installed application continues running if preparation fails before shutdown.

Update maintenance waits for active trading work, prevents concurrent cycles, patches changed release-owned files and keeps a durable rollback journal. It preserves private data, credentials, settings, owner reserves, cooldowns, logs and the trading STOP file. The download is a complete archive; installation is a file-level patch, not a binary-delta download or a fresh empty account.

The helper verifies the candidate's version/health before releasing maintenance. If application fails, it attempts to restore the program and environment from rollback copies. A failed or uncertain recovery remains visible and requires inspection. It must not force-stop a restored process that may be trading. Never delete an unknown RESTART/journal marker or replay a financial database backup over newer trading activity. Local exits cannot run during downtime.

After installation, a popup summarizes changes and offers the short critical change tutorial. The full release report and README retain detailed history. Guide lessons can be revisited in any order. Completing a lesson does not accept a risk-policy change or activate trading.

One-time maintenance for older unsigned clients

Releases with the old unsigned applier need a trusted manual upgrade to 0.4.0. Publishing a new ZIP does not patch old installations automatically. A newer ZIP cannot retroactively secure the old applier that would install it.

If you are upgrading from 0.3.x, use Quit Ballast and wait for shutdown before maintenance. Keep an offline backup of the installation and its private data. Do not unzip over a running installation or start a second copy against the same broker account. This first migration needs the verified maintenance procedure below; contact hello@ballastdigital.xyz for help. Do not send API keys or a raw trading database to support. Once on 0.4.0, use the signed in-app update flow.

The maintainer must identify the actual installation and published source, verify the new signed artifact independently, prepare dependencies and recovery copies, gracefully quit the existing application and wait for its exact supervisor/server to exit. Back up private state consistently. Apply only managed program files and retain trading settings. Resume according to the operator's requested state and verify the running version afterward.

Never overwrite a running batch launcher. An unknown legacy Start Ballast.new.bat is preserved and refused for review; it is not executed automatically. Never kill an unrelated process by port or copy an active SQLite database as ordinary files. Use the current installation's documented recovery procedure if any step is uncertain.

Maintainer release boundary

Every package requires verified published-baseline continuity, the full combined test suite, current hash-locked dependency audit, source/archive privacy scans, matching version/history/tutorial content and a trusted signature. Customer archives omit tests, internal engineering notes, private keys and vendor tools. Follow RELEASE-PROCEDURE.md and ENGINEERING-PROTOCOL.md from the maintained source.