Blora Panel v0.1.0-beta.2

Blora Panel v0.1.0-beta.2

Prerelease for hands-on evaluation, not a stable release.

Changes since beta.1

• Start Master and Daemon with one command and no additional arguments. Each
  reads its JSON configuration beside the installed executable; relative paths
  follow that installation directory rather than the shell working directory.
• Master defaults to local HTTP on 127.0.0.1:37861. Nginx can provide public
  HTTPS and forward the original client address and origin. Proxy-header trust
  can be restricted to configured IP/CIDR ranges with verifyProxyIPs.
• Administrators can check and apply prebuilt Release updates from Settings
  for Master and from Nodes for Daemon. The production machine does not fetch
  source or compile Go/Node applications.
• A stable launcher stages and verifies a fixed release revision, switches one
  management child at a time, and restores the previous compatible program if
  the candidate does not become ready. Daemon updates drain accepted operations
  and retain owned running instances and their independent input/log helpers.
• Update checks include archive and per-file SHA-256 digests, safe paths,
  executable identity, protocol compatibility, storage migration fingerprints,
  fresh administrator authorization and durable idempotent receipts.

Installation

Choose the Linux amd64 or Windows amd64 Master/Daemon archives. Master includes
the frontend; the separate Web and SDK archives are optional for independent
frontend hosting and extension development. Download SHA256SUMS and verify
the chosen archives before extraction.

Extract Master and Daemon into separate installation directories. Copy their
example JSON to master.json / daemon.json, create the Master's private
initial-password file, and follow START.txt and the production sections of
the English or Chinese README. There is no shared default password. External
TLS is normally handled by Nginx; never expose a backend that trusts arbitrary
forwarded headers directly to the public network.

Beta.1 does not have this update engine or metadata, so the first installation
of beta.2 requires the documented manual installation/maintenance procedure.
Subsequent compatible Releases can use the web update controls. The bundled
CORE-UPDATE.json also appears as a release asset for compatibility checks.

Validation boundaries

The final release's RELEASE-PROVENANCE.json records the fixed source, archive
digests and the checks actually completed on these build inputs. Earlier
source-specific results remain in the acceptance reports; they are not
automatically promoted to certification of this build.

• Linux online-update mechanism checks preserve the actual instance PID birth
  identity, run ID, input/log recovery and business heartbeat. Management
  connections can reconnect; interactive terminal sessions may end and browser
  uploads may need resuming.
• Windows binaries are cross-compiled and integrity-checked. The new Windows
  launcher/update/Job-keeper continuity path has not been device-tested; the
  previous 14-check Windows report covers its own earlier fixed commit.
• Online updates require compatible peer protocols and the same storage
  migration fingerprint. Incompatible schema changes, launcher changes and
  arbitrary downgrades require maintenance; there is no automatic patch chain.
• Existing update records include absolute paths. Moving an active production
  state/version tree is a separate migration, not a supported automatic rebase.
• The retained stress measurements are Chromium 38.8ms, Firefox 66ms and
  WebKit 89–132ms (last 95ms) on their recorded source. There is no universal
  50ms/100ms guarantee; the 200-line editor bulk-input limitation remains.

License

GPL-3.0-only. The matching source archive and tag accompany the binaries;
component archives include LICENSE and third-party notices.