Masterplan Optimiser
Run the service
Step 1 of 138%

For root and controller responsibilities

Build a service you can explain and recover

Running the Server means carrying both technical and organisational responsibility. Root protects the deployment; the declared controller decides why and how personal information is used. One person may hold both responsibilities, but the distinction should remain visible.

Plan a quiet setup window; stop safely whenever the TUI asks for an external action.

What you need before you start

  • A final domain in a Cloudflare-managed zone
  • One or two fresh supported Ubuntu VPSs with root SSH access
  • A trusted workstation with a passkey-capable browser
  • Real controller, provider, country, retention and contact decisions
  • Independent storage for encrypted recovery exports
  • SMTP credentials only if activation email will be enabled

Root commissioning

Administration unlocks only after all three browser steps and final Server verification.

  1. 1

    Recovery key

    Download and locally reselect the AGE identity

  2. 2

    Controller identity

    Generate or import an Ed25519 key and authorise it with the root passkey

  3. 3

    Governance baseline

    Review and publish immutable version 1

  4. 4

    Final checks

    Verify health, public notices and evidence, then seal the receipt

Work through the steps

  1. 01

    Prepare the final deployment

    Choose the final hostname, one or two Ubuntu VPSs, SSH access, a passkey-capable browser and independent recovery storage.

    You are ready to continue when: DNS, provider-console access and verified SSH access are ready.

    Open this step
  2. 02

    Install the signed release

    Run the supported bootstrap, reconnect as deploy and use mp-opt for the guarded setup.

    You are ready to continue when: The exact signed release serves healthy public HTTPS.

    Open this step
  3. 03

    Complete root commissioning

    Register the root passkey, protect the recovery key, establish controller trust and publish real governance facts.

    You are ready to continue when: Commissioning reports 100% and normal administration unlocks.

    Open this step
  4. 04

    Configure optional services

    Add SMTP, push or HA only when required, then review and publish the resulting governance diff.

    You are ready to continue when: Runtime features and the current public notice agree.

    Open this step
  5. 05

    Prove independent recovery

    Create, deep-verify and export a full snapshot. Keep its AGE identity away from both VPSs.

    You are ready to continue when: A verified external package is identified by package ID and SHA-256.

    Open this step
  6. 06

    Optionally add Node B

    Join the independent peer, verify the first encrypted copy and test planned handover and failover before enabling automation.

    You are ready to continue when: Both directions have passed and the two nodes report the same protected state.

    Open this step
  7. 07

    Make the routine sustainable

    Name the people responsible for health, updates, snapshot replacement, restore practice, rights requests, deletion evidence and incidents.

    You are ready to continue when: The cadence, custody locations and escalation route are written down and understood.

    Open this step

Snapshot recovery lifecycle

Creation is not recovery proof; the operator must verify custody and practise the guarded restore path.

  1. 1

    Create

    Capture configuration, database, evidence and protected state

  2. 2

    Deep verify

    Decrypt, inspect manifests and test database restore

  3. 3

    Export

    Move a workstation copy away from the VPS

  4. 4

    Confirm custody

    Record package identity without claiming remote deletion

  5. 5

    Restore

    Take a pre-restore point, restore, migrate and check health

  6. 6

    Replace

    Create and verify a fresh post-restore recovery point

Critical HA replication barrier

Ordinary writes retain the declared RPO; narrow credential, link and deletion operations wait for exact peer proof.

  1. 1

    Commit + marker

    Mutation and durable protection row share one transaction

  2. 2

    Witness guard

    Failover is fenced while the operation is unresolved

  3. 3

    Capture

    Critical requests are batched into an encrypted complete bundle

  4. 4

    Peer verifies

    Node B proves the exact database marker and evidence generation

  5. 5

    Receipt

    Minimal UUID-addressed result is readable by the backend

  6. 6

    Success

    Only accepted peer proof unlocks the resource and user-visible success

Evidence sealing and portable verification

The exported ZIP carries the chain, public keys and verification result; private keys never belong in it.

  1. 1

    Canonical record

    Bounded facts and receipt digests

  2. 2

    Domain signature

    Controller, processor, root action or instance seal as applicable

  3. 3

    Chain link

    Previous digest and current record digest

  4. 4

    Evidence repository

    Append-only archive or guarded private mirror

  5. 5

    Portable ZIP

    Records, public keys and verification report

  6. 6

    Offline verifier

    Checks every signature, link and required artifact

Exact operator procedures

Server documentationServer setupSigned installation, commissioning prerequisites and deployment contracts.Detailed procedure · opens the canonical GitHub Pages siteServer documentationServer managementThe guarded TUI, snapshots, recovery and normal operation.Detailed procedure · opens the canonical GitHub Pages siteServer documentationHigh availabilityTwo-node replication, handover, witness and failover procedures.Detailed procedure · opens the canonical GitHub Pages siteEvidence-PublicVerify a complete chainInspect an exported evidence chain locally in the browser.Browser tool · opens the canonical GitHub Pages site