Hosting TOKN

This document describes a future deployment shape. The local Docker artifacts are prepared, but this document does not claim that cloud hosting, DNS, TLS, or an HTTPS wallet endpoint is deployed.

Bootstrap host

Use a small Linux host with Docker Compose, persistent disk, and enough memory for Besu, Tor, the gateway, and the wallet/tool images. Keep the validator key, creator/treasury keys, onion identity, database, and encrypted backups on private storage. Verify the release checksums and manifest before starting the stack. An ordinary independent-key peer must create its own validator and onion identities; never copy creator, treasury, validator, or onion keys from the bootstrap host. A second container on the same operator's machines is not an independent validator.

The onion route is the current remote transport. Set TOKN_TOR_SNOWFLAKE=1 when direct Tor bootstrap is blocked; both the full-node and wallet compose files pass the setting to the Tor image. Public RPC should remain behind the gateway allowlist.

Future web endpoint

The planned web stack uses the existing gateway behind Caddy 2.11.4 for TLS, with compose.web.yaml and these commands:

just site-build
just site-preview       # local preview at port 49944
just web-plan           # offline plan
just web-check
just web-dns            # dry run
just web-dns --apply    # explicit single-record apply after preflight
just web-deploy

The local artifacts and commands are prepared; actual DNS, HTTPS, and Netcup deployment are not claimed as live. Before remote work, preflight must find SSH known-hosts, Docker Compose, rsync, and Python 3, and deployment must use transferred build artifacts rather than a remote npm build.

When deployment credentials are supplied, use a minimal Cloudflare token scoped to DNS edits for the exact zone. Keep it in the local .env only; never expose it to the browser, release archive, logs, or Botsync. Netcup API credentials and an SSH destination likewise remain operator-supplied private configuration. DNS changes default to a dry-run. An explicit just web-dns --apply may set the single supplied host A/AAAA record after safe preflight and must never overwrite unrelated records. Do not make purchases or create broad API keys; the Cloudflare token is never copied to the remote host. Caddy uses HTTP/TLS challenges on ports 80/443 and does not need the Cloudflare token or a DNS module.

Before any deployment, run the offline plan/checks, verify the exact public allowlist, and confirm that no secrets or live databases are mounted into the public web service. Cloud/DNS deployment requires the supplied host and credentials plus a recorded verification receipt.

References: Cloudflare API token permissions, Caddy automatic HTTPS, and Netcup SCP REST API. Netcup's optional SCP API credentials come from its panel; they are not CCP DNS credentials.