5.3 KiB
Executable File
Deployment, private monitoring, and recovery
Production remains NO-GO. These procedures are operator preparation, not an installed public edge, configured alerts, independent review, or deployment approval. Do not remove persistent node volumes as part of source cleanup.
Reverse-proxy trust
WIKIDECK_TRUSTED_PROXIES is empty/untrusted by default. It accepts up to 16 comma-separated literal IPs or bounded CIDRs. Configure only the actual source address of a trusted edge connection. The edge must overwrite forwarded headers, and firewall rules must prevent direct backend access. A trusted-proxy setting does not configure the firewall.
The nginx example is not installed or deployment-validated. Replace its reserved hostname and certificate paths, and validate TLS, renewal, forwarded-IP handling, body/connection/time limits, and edge admission controls on the intended host. Container proxy source addresses may differ from host loopback; inspect the actual topology instead of copying a trust list blindly.
Private diagnostics
Set WIKIDECK_OPS_PORT to an unused port (1–65535) to enable a separate HTTP listener bound to 127.0.0.1; leave it unset to disable it. Never publish or reverse-proxy this port. Only GET /status is supported. It returns bounded, no-store aggregate JSON; any local process with loopback access can read it.
Reported diagnostics include node uptime/RSS, event-loop delay, canonical height and tip age, DAG and pending counts, native-engine status, configured/connected peers, RPC budgets, and available disk plus ledger database/WAL sizes. Native subprocess memory is not included in Node RSS. Peer count is not a security score. Health is liveness, not sync readiness or consensus assurance.
ops:check -- --port <private-port> reads only literal loopback with bounded time and response size. It emits warnings for stale/empty chain, peer isolation, native-engine failure, queue pressure, event-loop delay, and unavailable/low disk. Thresholds are starting points, not production SLOs. Route alerts to an external system and test delivery; this repository does not install a scheduler or alert destination.
Stopped-node ledger backup
node:backup supports create, verify, and restore. New version-2 packages contain only the selected network's ledger database. Stop the node cleanly first; the tool takes the same exclusive network lock as startup, uses SQLite VACUUM INTO, checks SQLite integrity and chain metadata, hashes the snapshot, and writes the manifest last. It refuses to overwrite a destination, restore in place, or run when a node lock exists. Restore targets must not exist.
Example workflow, using the node:backup package command with explicit --source, --destination, and --consent as required by the CLI:
- Stop the node and confirm all writers to its data directory are stopped.
- Create the backup in a new directory outside the node data directory. Keep wallet backups separately; this tool does not include browser wallets, secrets, configuration, binaries, or logs.
- Run
verifyagainst the backup before copying it off-host. - Restore only to a new isolated data directory. The tool reports
proofsRevalidated: false; reopen with the trusted RandomX implementation and verify the chain before resuming service.
Backups are not encrypted or authenticated by this tool. Store them in restricted, encrypted off-host storage, protect the manifest separately, and test cold restoration. Hashes detect accidental corruption, not a coherent malicious replacement. Filesystem, power-loss, Windows ACL, and network-share durability need validation on the actual storage platform.
Retiring legacy financial data safely
Removing market/custody source code does not delete or resolve data left by an older deployment. The card-only node does not open or reconcile those files. If the selected network directory contains market.sqlite, custody-sandbox.sqlite, or a custody-postgres.json binding, new ledger-only backup creation refuses to proceed rather than silently omit those records. Preserve the existing volume and any PostgreSQL database; arrange an operator-reviewed archive before retiring it.
Historical version-1 paired backups containing ledger.sqlite and market.sqlite remain verifiable and restorable as opaque files for preservation. Restoration does not reactivate market services or imply that financial obligations have been resolved. External PostgreSQL data is not contained in a SQLite package. Do not delete old volumes, journals, database credentials, or backups as part of this source cleanup.
An operator must choose retention, recovery point/time objectives, off-host storage, and restore ownership. Never remove a lock or replace a running volume just to make recovery succeed.
Remaining operational evidence
Verify the intended HTTPS/proxy/firewall topology, peer and tip freshness, alert delivery, disk growth, backup encryption/retention, and restore/replay time on the actual host. Assign an incident responder and document stop/rollback criteria. See the card-only production plan, operator launch register, and security review. No startup or payment approval is granted by these tools.