Skip to main content
Hoox uses a dual-layer configuration topology: a declarative build-time environment layer (managed via local files and Cloudflare Secrets) and an instantaneous runtime configuration layer (managed via Cloudflare KV key-value databases). This ensures maximum agility: deploy secure code once, and adjust trading parameters or flip kill switches in real-time without redeploying code.

1. Declarative Environment Variables (.env.local)

For local operations, build-time variables, and workspace linking, Hoox loads a .env.local file at your project root. Copy the secure template during initialization:
The Hoox environment is split into 5 core logical sections. Below is the comprehensive dictionary of key configuration parameters:

A. ⚡ Cloudflare Core Infrastructure

B. 💱 Exchange API Keys (Securely Redacted)

These credentials must be injected as secure encrypted environment variables into your Cloudflare Worker isolates. The Hoox CLI automates this injection.
  • Binance:
    • BINANCE_API_KEY — Your read/write exchange account trade permission key.
    • BINANCE_API_SECRET — Private secret key used to HMAC-SHA256 sign order payloads.
  • Bybit:
    • BYBIT_API_KEY — Order routing account key.
    • BYBIT_API_SECRET — Order signing private key.
  • MEXC:
    • MEXC_API_KEY — Order routing account key.
    • MEXC_API_SECRET — Order signing private key.

C. 💬 Telegram Bot Alerts

D. 🧠 Multi-Provider AI Credentials

Used to power autonomous risk assessments, Telegram conversation loops, and time-series summaries in agent-worker.
  • OPENAI_API_KEY — Access key for OpenAI GPT models.
  • ANTHROPIC_API_KEY — Access key for Anthropic Claude models.
  • GOOGLE_AI_API_KEY — Access key for Google Gemini models.

2. Managing Environment & Secrets via CLI

To prevent plain-text exposure and ensure proper edge variable binding, never manually paste sensitive keys into wrangler.jsonc files. Instead, utilize the high-integrity hoox config env command groups:
Decrypted .dev.vars files contain local environment credentials and are excluded from git history via .gitignore automatically. Running hoox config env generate-dev-vars ensures that local worker testing via bun run dev has access to simulated credentials safely.

3. Worker Configurations (wrangler.jsonc)

Each worker in the monorepo has a standard wrangler.jsonc file at its directory root. These configurations declare:
  1. Service Bindings: Connects gateway routes (hoox) to internal compute units (trade-worker, d1-worker) directly via microsecond V8 isolates—no TCP/TLS overhead, no public routes.
  2. Resource Bindings: Declares which D1 databases, R2 storage buckets, and KV configurations are linked.
  3. Execution Mode: Toggles latency-saving features like Smart Placement ("placement": { "mode": "smart" }).
You can inspect, check, or change worker toggle status directly:

4. Runtime KV Configuration (Sub-millisecond Settings)

One of Hoox’s core architectural features is instant runtime parameter updates. By using Cloudflare KV, certain settings can be modified globally in sub-milliseconds and take effect on the very next signal execution—without rebuilding or redeploying any worker. Hoox manages a standard 16-key runtime manifest inside the CONFIG_KV namespace. Below are the most critical runtime parameters:

Managing KV Settings via CLI


Changed exchange configurations or toggled the kill switch? There is no need to redeploy. The changes are distributed across Cloudflare’s 330+ global edge locations near-instantaneously!

🔗 Next Steps

Last modified on June 17, 2026