Skip to main content

​
Advanced Installer Reference

This page is for exact release selection, repair, automation, and failure recovery. Normal users should start at Install or VPS Hosting.

​
Exact-tag pre-execution verification

This procedure authenticates a tagged install.sh before Bash executes it. Install GitHub CLI from your operating system’s signed package source, choose a stable release, and replace vX.Y.Z:
For a Local install, change only the final line to:
Stop if any download or verification step fails.

​
Hosting repair and recovery

Streamed Hosting is fresh-install-only. Existing-host repair must reuse the exact-tag block above and change only its final line:
Use repair only when the installed updater or root-managed services cannot recover normally. Never pipe --repair-hosting from mutable main, pass a caller-created verified marker, or grant the operator broad sudo access. The streamed bootstrap reports which recovery path applies:
  • no persistent Fased installer state: fix the prerequisite and rerun the exact fresh Hosting command;
  • persistent installer state: use exact-tag repair;
  • working installation: reconnect as app and use fased update.

​
Public modes

Run ./install.sh --help from a trusted checkout for the current complete surface.

​
Streamed Hosting restrictions

The exact normal Hosting command accepts only --hosting. Before tagged payload verification it rejects:
  • repair, source, development-channel, release, and host-profile selectors;
  • caller-supplied --verified-hosting-bundle markers;
  • exported FASED_* values;
  • proxy, custom CA, GitHub CLI config, dynamic-loader, shell-startup, and temp directory overrides; and
  • hosts with existing Fased state, services, helpers, or installer roots.
It uses a fixed command path and locale. Before persistent Fased mutation it verifies the offline-attested release manifest, workflow, exact tag, commit, architecture, app/dependency/signer digests, archive paths, links, ownership, writable modes, package version, and build identity.

​
Runtime and account layout

Local uses the same fased wallet commands under the local OS account. Hosting routes those commands through the restricted operator socket, so create, import, recovery, raw export, RPC changes, and Mining retirement do not require undocumented root helpers.

​
Wallet setup contract

  • The operator chooses agent, mining, or vault; the role is permanent.
  • Create/import/recovery installs signer-owned role baseline v1 and one verified primary RPC as one resumable lifecycle.
  • New Agent and Vault wallets are ready for reviewed owner actions. Automation still needs explicit caps, destinations, programs, and grants.
  • New Mining wallets become SAT-ready only when the release-bound SAT manifest is verified; funding is still required.
  • Existing legacy deny-all wallets are never expanded silently. Review the role and explicitly run fased wallet policy activate-role-baseline ... --confirm.
  • Creating an Agent wallet does not silently make it the Default Agent wallet.
See Wallet CLI, roles and policies, and wallet selection.

​
Environment variables

The following are advanced Local or trusted-file controls. Exported FASED_* variables are rejected by the normal streamed Hosting path. Do not place wallet keys, recovery passwords, Tailscale secrets, or provider credentials in environment variables, command arguments, chat, or browser requests.

​
Exit and recovery behavior

The installer stops on failed prerequisite, attestation, digest, archive, identity, service-health, or updater checks. Hosting activation is staged and locked; failure cleanup removes temporary extraction and leaves either no persistent Fased state or a specific exact-tag repair instruction. Normal updates are transactional: the updater stages an immutable release, checks runtime identity and health, and rolls back activation if the new Gateway does not become healthy.