Root & controller
Deploy, govern and verify MP-OPT step by step
Root is the deployment's privileged technical role; controller is a declared legal responsibility. They may be held by the same person, but the software does not infer that relationship. Follow this sequence before admitting real event data.
What you need before starting
Domain and DNS
A final application hostname in a Cloudflare-managed zone. For HA, prepare the required zone-scoped DNS token and guarded worker/witness deployment access.
Server host
One fresh Ubuntu 22.04 or 24.04 VPS with a public address, provider-console access and SSH root access using a verified public key.
Optional HA peer
A second independent Ubuntu VPS with equivalent access. Start with standalone unless two-node availability is actually required.
Trusted workstation
A current browser, passkey-capable authenticator/password manager, secure file storage and a separate destination for encrypted recovery exports.
Controller decisions
Real controller identity and contact, purposes, legal bases or Swiss justification, processors, countries/transfers, retention, rights and incident routes.
Delivery choices
SMTP provider credentials and countries if email is enabled; decide whether browser push, public links, offline data and HA will be enabled.
Do not start with: an already-used database, a temporary hostname, password-only SSH, real protected data, or a recovery key stored on the VPS it must recover.
Root commissioning
Administration unlocks only after all three browser steps and final Server verification.
1
Recovery key
Download and locally reselect the AGE identity
2
Controller identity
Generate or import an Ed25519 key and authorise it with the root passkey
3
Governance baseline
Review and publish immutable version 1
4
Final checks
Verify health, public notices and evidence, then seal the receipt
Complete setup path
- 01Open guide
Choose the deployment and final hostname
Decide standalone or two-node HA, point DNS to the first VPS and verify the provider console and SSH host fingerprint.
Done when: The final hostname resolves as intended and SSH root access works.
- 02Open guide
Install the signed Server release
Provision the host, reconnect as the generated deploy user and start the guarded TUI installation workflow.
Done when: The exact signed release is installed and public HTTPS health is healthy.
- 03Open guide
Complete root commissioning
Register the root passkey, download and reselect the AGE recovery identity, create the controller key, publish governance version 1 and run final checks.
Done when: The setup page reports 100%, bootstrap is retired and administration unlocks.
- 04Open guide
Review data protection and governance
Confirm the controller, providers, countries, transfers, features and retention reflect the real deployment—not examples or inferred facts.
Done when: Public notices match the published SHA and contain no placeholder or contradiction.
- 05Open guide
Configure optional delivery
Configure SMTP and send a synthetic test message. Configure push only if declared and required; republish governance after material runtime changes.
Done when: Configured delivery works and the current governance version matches runtime facts.
- 06Open guide
Prove recovery
Create, deep-verify and export a full snapshot. Confirm the workstation copy and protect the private AGE identity away from both VPSs.
Done when: A verified external recovery package can be identified by package ID and SHA-256.
- 07Open guide
Create bounded operators
Add a second root passkey if appropriate, then create global admins, event admins or issuers with only the authority they need.
Done when: There is no shared root credential and every operator can authenticate independently.
- 08Open guide
Verify the first end-to-end event
Create one synthetic event, enrol its Desktop processor, publish, activate a participant and check authenticated/public/PDF output.
Done when: Publishing, passkeys, audiences and recovery complete without unresolved warnings.
- 09Open guide
Optionally commission HA
Join Node B, publish updated governance, test planned handover and automatic failover in both directions before enabling it.
Done when: Both nodes converge on exact state, failover tests pass and automatic failover is deliberately enabled.
- 10Open guide
Establish routine operation
Schedule health, updates, snapshot replacement, restore exercises, rights handling, deletion evidence, key review and incident response.
Done when: Named people know the cadence, custody locations and escalation route.
Keys are independently generated. Arrows show responsibility, never derivation.
Controller Ed25519
Controller trust and governance statements
Event processor Ed25519
Desktop policy, deletion and local-copy receipts
Root passkey
Human authorisation of privileged Server actions
Instance evidence key
Evidence-chain and final-receipt sealing
Verifiable evidence
Exact statements, signatures, digests and chain links—not proof of physical deletion outside controlled systems
Deletion case state machine
The workflow records accountable progress; it does not silently equate a database command with complete erasure.
1
Request
User or whole-event scope is fixed
2
Desktop work
Every snapshotted processor returns signed receipts
3
Server purge
Live Server data is transactionally removed
4
Recovery resolution
Pre-purge local snapshots and known external copies are resolved
5
Root closure
Root reviews exact receipts and confirms completion
6
Evidence sealed
Instance key appends the final chain record
Deletion proceeds on parallel accountable tracks
A case completes only after every applicable track has evidence or an explicit bounded resolution.
Server
Purge live data; record HA peer confirmation
Desktop
Delete event/person data; resolve local exports
Recovery
Create clean replacement; remove only pre-purge local snapshots
External copies
Operator confirms copies outside controlled systems
Evidence
Verify every required digest before root closure
Evidence sealing and portable verification
The exported ZIP carries the chain, public keys and verification result; private keys never belong in it.
1
Canonical record
Bounded facts and receipt digests
2
Domain signature
Controller, processor, root action or instance seal as applicable
3
Chain link
Previous digest and current record digest
4
Evidence repository
Append-only archive or guarded private mirror
5
Portable ZIP
Records, public keys and verification report
6
Offline verifier
Checks every signature, link and required artifact
Action-first SMTP delivery
Participant mail is sent only when published controller and processor facts match the running SMTP configuration.
1
Authorised request
Activation, reset or additional passkey
2
Governance check
Controller, contact, provider and countries must be published
3
Bounded message
Action, expiry, inline QR and compact privacy contact
4
SMTP provider
Controller-declared delivery service
5
Recipient
Uses the one-time fragment; no tracking or remote assets
Critical HA replication barrier
Ordinary writes retain the declared RPO; narrow credential, link and deletion operations wait for exact peer proof.
1
Commit + marker
Mutation and durable protection row share one transaction
2
Witness guard
Failover is fenced while the operation is unresolved
3
Capture
Critical requests are batched into an encrypted complete bundle
4
Peer verifies
Node B proves the exact database marker and evidence generation
5
Receipt
Minimal UUID-addressed result is readable by the backend
6
Success
Only accepted peer proof unlocks the resource and user-visible success
Snapshot recovery lifecycle
Creation is not recovery proof; the operator must verify custody and practise the guarded restore path.
1
Create
Capture configuration, database, evidence and protected state
2
Deep verify
Decrypt, inspect manifests and test database restore
3
Export
Move a workstation copy away from the VPS
4
Confirm custody
Record package identity without claiming remote deletion
5
Restore
Take a pre-restore point, restore, migrate and check health
6
Replace
Create and verify a fresh post-restore recovery point
Use the canonical Server documentation for exact TUI, SMTP, snapshot, HA and incident-recovery procedures.
Evidence-Public tools
The public static tools run locally in the browser. They prepare public packages or inspect an exported evidence chain without uploading private key material.