Protected Vorliq Operator Dashboard

Set ADMIN_TOKEN On Production

The backend service should load the token from a root-owned private environment file. Generate the value in a private operator shell, never in public docs or shared support channels.

sudo systemctl daemon-reload
sudo systemctl restart vorliq-backend.service

The backend service can load it from a private operator-controlled environment file.

Use The Dashboard Safely

• Use Overview to verify deployment, block height, chain validity, pending transactions, incidents, backups, and service state.
• Use Readiness to review the combined production gate, score, failing checks, warning checks, latest backup age, storage counts, incident counts, registry counts, deployment commit, and safe service names.
• Use Network Monitor to review ok, warning, or critical node monitor status, fork/stale/ahead alerts, and safe operator actions.
• Use Registry Lifecycle to archive old test nodes, restore nodes that return, or retire nodes without deleting registry history.
• Use Storage to review JSON validity, backup availability, warning counts, and corruption signals without exposing server paths or secrets.
• Use Indexes to review derived read-index status, chain match, build time, and to trigger a safe rebuild from chain.json when needed.
• Use Migration to confirm production is still on JSON storage, the active adapter is JSON, PostgreSQL adapter writes are blocked, and dry-run plus shadow rehearsal migration preparation is available.
• Use Security to confirm rate limits, CORS, Helmet, CSP, public write protection, and admin route protection.
• Use Backups to run a backup and verify the latest archive. Verification never restores production data.
• Use Incidents to create and resolve public incident records when users need visibility.
• Use Reports to review spam, impersonation, abuse, scam, illegal-content, and other reports without automatically deleting content.
• Use Forum Moderation to hide, unhide, lock, unlock, pin, unpin, feature, or unfeature posts without deleting historical records.
• Use Chat Moderation to review recent in-memory public chat messages and hide future-history copies when practical.
• Use Profiles to inspect public verification and reputation signals. Admins cannot fake wallet verification.

Post-Deploy Checks

After deployment, verify the public app, /api/health, /api/deployment, /api/version/metadata, /api/system/self-check, /api/storage/health, /api/migration/readiness, /api/readiness, /api/nodes/compare, /api/nodes/monitor, the registry summary, and the status page. CI also runs read-only Playwright browser tests against production so route loading, mobile navigation, layout overflow, safe API responses, and non-destructive user journeys are checked before the deploy workflow runs. The deploy workflow then runs the public readiness CLI; a fail result blocks the workflow.

Operators with the admin token can review /api/admin/readiness, /api/admin/nodes/compare, or /api/admin/nodes/monitor for deeper safe metadata. Do not paste admin tokens into public reports, screenshots, or issue comments.

Use the Run Your Own Node guide for verified community onboarding, use Verified Chain Bootstrap for dry-run-first public chain import, and use the Upgrade Guide before updating self-hosted nodes.

Signed Snapshots

Production snapshots are signed with an Ed25519 key stored outside the repository. Generate a snapshot signing keypair locally or on the server, store the private key only as a production secret, and publish the public key and key id. Do not commit the private key and do not put it in frontend code.

node tools/generate_snapshot_keypair.js

# Add these securely to a private environment file outside the repository:
VORLIQ_SNAPSHOT_PRIVATE_KEY: redacted
VORLIQ_SNAPSHOT_PUBLIC_KEY: redacted
VORLIQ_REQUIRE_SNAPSHOT_SIGNATURE: true

sudo systemctl restart vorliq-backend.service
node tools/verify_snapshot.js https://vorliq.org --require-signature
curl https://vorliq.org/api/snapshot/public-key

The environment file should be root-owned with restrictive permissions. Rotate keys by publishing the new public key id, updating the private/public key secrets, restarting the backend, and keeping old public keys documented for historical verification. In an emergency, disable the signature requirement privately, restart, and report the reason.

Signed snapshot archives are written during deploy after snapshot verification passes and by cron at the configured operator schedule. The archive job loads private operator environment files, runs backend/archive_snapshot.js, and writes public archive files for verification. The backend keeps the latest 30 public archives. Verify the archive with node tools/verify_snapshot_archive.js https://vorliq.org and bootstrap-check the public node with node tools/bootstrap_verify_node.js https://vorliq.org.

Storage Reliability

Vorliq JSON state is protected with atomic writes, backup-before-write .bak files, lightweight write locks, safe JSON loading, and storage health reporting. The public and admin storage endpoints return file names and health metadata only, never raw file contents, full server paths, private keys, wallet passwords, or admin tokens.

Derived index health is available at /api/indexes/health. Protected operators can call /api/admin/indexes/rebuild to rebuild indexes.json without rewriting chain.json or changing block hashes.

Migration readiness is available at /api/migration/readiness. Protected operators can review deeper safe metadata at /api/admin/migration/readiness. Production should continue to report storage_backend: json, active_storage_adapter: json, database_enabled: false, postgres_active: false, postgres_adapter_enabled: false, and postgres_write_mode: disabled until a future migration is explicitly planned and verified.

Read the Storage Reliability guide before responding to corruption warnings or restoring from backup.

Read Storage Adapters, Storage Adapter Interface, PostgreSQL Adapter, Schema Map, PostgreSQL Readiness, PostgreSQL Shadow Migration, Database Migration Plan, and Database Rollback Plan before planning any database migration.

Controlled Public Node Miner

The optional public miner service is disabled by default. It does not hold private keys and it does not bypass proof of work. When enabled, it checks /api/mining/status and only attempts a block when the chain is valid and the block-time rules allow mining.

sudo systemctl edit vorliq-miner.service

[Service]
VORLIQ_PUBLIC_MINER_ENABLED: true
VORLIQ_PUBLIC_MINER_ADDRESS: VLQ_PUBLIC_MINER_ADDRESS
PUBLIC_MINER_API_URL: https://community-node.example

sudo systemctl daemon-reload
sudo systemctl enable --now vorliq-miner.service

To disable it, run sudo systemctl disable --now vorliq-miner.service. Never add private keys, admin tokens, SSH keys, or wallet passwords to the miner service.

Community Node Doctor

Community operators can run the read-only doctor after install or update. It checks local health, chain summary, diagnostics, storage, indexes, readiness, trusted snapshot verification, node sync comparison, node monitor alerts, peer propagation status, registry metadata, and local systemd services when available. ahead is not automatically trusted; use signed snapshot and audit export checks. Recover forked nodes with dry-run bootstrap first and do not manually edit chain.json.

Do not manually edit registry.json. To remove old stale/test nodes from default live views, use Registry Lifecycle or POST /api/admin/registry/archive with a clear reason. Restore returns the node to heartbeat-based classification. Retire marks intentional departure. The trusted public node should not be archived casually and requires an explicit force flag.

Peer propagation status is available at /api/peers/propagation/status and the live Peer Propagation page. Broadcast may remain disabled by default; receive validation can still quarantine unsafe blocks and reject invalid transactions.

node tools/node_doctor.js --base-url https://community-node.example --public-url https://node.example.org --trusted-node https://vorliq.org