Secrets & Network Security
How to manage encrypted Cloudflare® Worker Secrets, secure Zero Trust service boundaries, and configure edge firewalls and IP allowlists.
This page
Security is the most critical component of the Hoox trading platform. When deploying automated execution scripts, your capital and API credentials must be protected against malicious exploits, unauthorized webhook payloads, and network interceptions.
This guide outlines our Zero Trust security architecture, encrypted secret management procedures (including sync modes), and edge-level firewall protection runbooks. Prefer hoox secrets over manual wrangler secret put for day-to-day ops.
🛡️ 1. Zero Trust Network Isolation
Traditional trading systems expose database and exchange execution APIs to the public internet (secured by simple HTTP headers or ports). This creates an active attack surface.
Hoox implements a strict Zero Trust microservice isolation topology:
[Public Internet] ───► [Cloudflare® WAF / Firewall]
│
(IP & Auth Checks)
│
▼
[Gateway (hoox)] (Publicly Accessible Node)
│
┌────────────────┴────────────────┐
│ V8 Isolate Service Bindings │
│ (Private, Encrypted, Zero-TCP) │
└────────────────┬────────────────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
[trade-worker] [d1-worker] [agent-worker]
(No Public URL) (No Public URL) (No Public URL)
│ │ │
(Exchange Orders) (SQLite Queries) (AI Risk Audits)
- No Public Endpoints: The
trade-worker,d1-worker, andagent-workerliterally do not exist on the public internet. They have no public IP addresses or URLs. - V8 Service Bindings: Communication between the public gateway (
hoox) and internal compute nodes is routed entirely inside Cloudflare®'s secure V8 engine isolates. Your trade routing data, database queries, and private logs never travel over the public internet, eliminating TLS decryption and packet-sniffing risks.
🔑 2. Encrypted Secret Management via CLI
API keys, exchange secrets, and Telegram bot tokens are never committed to git repositories or written in plain-text configuration files. Instead, they are stored directly on Cloudflare®’s hardware-secured key vaults. Local writers chmod secret files 0600.
The Hoox CLI features deep encryption integrations to automate secret provisioning:
# 1. Unified exchange pair (Binance / Bybit / MEXC — venue comes from the signal)
hoox secrets set trade-worker EXCHANGE_KEY_BINDING
hoox secrets set trade-worker EXCHANGE_SECRET_BINDING
# 2. Optional: dedicated testnet pair (preferred when webhook has "test": true)
hoox secrets set trade-worker EXCHANGE_TESTNET_KEY_BINDING
hoox secrets set trade-worker EXCHANGE_TESTNET_SECRET_BINDING
# 3. List edge secret names for a worker (values are never printed)
hoox secrets list trade-worker
# 4. DEX: Jupiter portal key (Solana). Mesh WALLET_EXECUTE + Solana seed come from hoox setup.
hoox secrets set web3-wallet-worker JUPITER_API_KEY
# 5. After key rotation: push mesh/system secrets only (INTERNAL_KEY_BINDING, WALLET_EXECUTE_*, WEBHOOK_*, …)
hoox secrets sync --system
# Alias: hoox secrets sync --required
# 6. Push all declared secrets from .dev.vars
# Partial results report synced / skipped (placeholders) / failed
hoox secrets sync
Secret sync modes
| Mode | Flag | Behavior |
|---|---|---|
| Full | hoox secrets sync | Sync every declared secret from .dev.vars (skips empty/placeholder values). Clones empty optional satellites first. |
| System / required | --system or --required | Mesh keys only (INTERNAL_KEY_BINDING, webhook passkeys, …) across every configured worker — safer after rotation |
| Skip during setup | hoox setup --skip-secrets | Generate keys / infra without pushing secrets (load later from .keys/setup.env with --skip-keys when appropriate) |
Optional satellites (pyne-worker, pyne-agent-worker): hoox secrets set <worker> <name> enables and clones them when missing from wrangler.jsonc or when the checkout is empty. Pass --yes to skip the enable prompt.
Live vs testnet exchange secrets
One unified key pair is used for all venues. The exchange (Binance / Bybit / MEXC) is chosen by the signal payload and routing config — not by secret name.
| Binding | Used when |
|---|---|
EXCHANGE_KEY_BINDING / EXCHANGE_SECRET_BINDING | Live orders on the routed exchange |
EXCHANGE_TESTNET_KEY_BINDING / EXCHANGE_TESTNET_SECRET_BINDING | Preferred for "test": true (Binance / Bybit) |
Legacy per-venue bindings (BINANCE_*, BYBIT_*, MEXC_*) still resolve as fallbacks if the unified pair is unset. If a testnet pair is missing, trade-worker falls back to the live pair and logs a warning.
See Test Trading.
Listing Edge Secrets
Running hoox secrets list queries Cloudflare® for secret names bound on the worker, without ever exposing or decrypting the actual values in your terminal. Use hoox check setup for a broader secrets-presence audit during system validation — it stays quiet when local secrets are healthy and remote names are complete, and only fails when declared secrets are missing on Cloudflare® (with hoox secrets sync hints).
🧱 3. Webhook Firewall & TradingView® IP Allow-listing
To ensure that only TradingView®'s official servers can fire signals to your /webhook gateway:
Passkey Verification: The gateway checks the
apiKeyproperty inside the JSON payload against your secure manifest inCONFIG_KV.Cloudflare® WAF (Web Application Firewall): Since TradingView® publishes their official IP ranges, you can configure Cloudflare®'s edge firewall to block all webhook traffic that does not originate from these verified IPs.
hoox waf status
hoox waf rules list
# Types: ip-allowlist, ip-blocklist, rate-limit, custom
hoox waf rules add ip-allowlist 52.89.214.238
hoox waf mode enable
TradingView® publishes webhook source IPs. Add each range with hoox waf rules add ip-allowlist <ip> (there is no --TradingView®-only flag). The gateway also honors webhook:tradingview:ip_check_enabled and webhook:tradingview:allowed_ips in CONFIG_KV.
📋 4. Security Best Practices Checklist
- Least Privilege API Keys: When creating API keys on Bybit, Binance, or MEXC, never enable "Withdrawal" permissions. Only check "Trade" and "Account Read" permissions.
- Credential Rotation: Automatically rotate your exchange API keys every 90 days. Deleting old keys and injecting new ones takes less than 60 seconds with
hoox secrets set. - Zero-Commit Rule: Verify that your
.env.localand.dev.varsfiles are registered in your workspace's.gitignorefile to prevent accidental pushes to public repos. - Emergency Response: If you suspect a strategy error or exchange anomaly, immediately halt all execution via the CLI:
hoox monitor kill-switch on
🔗 Next Steps
- Platform Configuration Guide — Map environment variables, secrets, and KV runtime settings.
- Local Development & Testing — Run local wrangler sandboxes with securely encrypted
.dev.vars.