[5-Minute Quick Start]
Deploy your first edge-native trading infrastructure on the Cloudflare Edge and fire a simulated trade webhook in under 5 minutes.
This guide gets you from a blank console to a fully active, edge-deployed algorithmic trading ecosystem on the Cloudflare network, processing simulated signals in under 5 minutes.
v0.8.0: The recommended entry point is now
hoox onboard(one-shot bootstrap) instead of runninghoox initandhoox setupseparately.
Step-by-Step Deployment Path
Step 1: Onboard Your Workspace
Run the one-shot bootstrap to collect your Cloudflare credentials, write wrangler.jsonc, and provision all infrastructure end-to-end:
hoox onboard
Interactive prompts will ask for your Cloudflare Account ID, API Token, and your unique SUBDOMAIN_PREFIX (e.g., alpha-trading). For non-interactive use, pass --token and --account flags.
If you want fine-grained control over each step, run them separately:
hoox init # 1. Write wrangler.jsonc and collect integration secrets
hoox setup # 2. Generate keys, apply D1 schema, push secrets, deploy dashboard
Step 2: Inject Encrypted Exchange API Keys
For your safety, exchange credentials (API keys and private signatures) are never stored in plain text. Inject them as encrypted Cloudflare Workers Secrets bound securely to your compute instances:
# Inject Bybit Credentials (worker name is the first argument)
hoox secrets set trade-worker BYBIT_KEY_BINDING "your_bybit_key_here"
hoox secrets set trade-worker BYBIT_SECRET_BINDING "your_bybit_secret_here"
# Optional: Inject Binance Credentials
hoox secrets set trade-worker BINANCE_KEY_BINDING "your_binance_key_here"
hoox secrets set trade-worker BINANCE_SECRET_BINDING "your_binance_secret_here"
Warning
Cloudflare Secrets are encrypted at rest using hardware-level keys and are injected straight into your V8 execution isolates at runtime. They can never be decrypted or read back via the API, ensuring top-tier security for your capital.
Step 3: Deploy All Workers in Sequence
Hoox microservices communicate internally via Service Bindings. The CLI automatically manages the deployment sequence, ensuring databases, queues, and configuration stores compile first, followed by gateway routers and background compute tasks:
# Compile and deploy all enabled workers
hoox deploy all --auto
This command automatically provisions:
D1 Edge Database (
hoox-db)CONFIG_KV configuration namespace
Internal Workers (
trade-worker,d1-worker,telegram-worker)Public Gateway (
hooxgateway router)Next.js Dashboard Command Center (
workers/dashboard)
Once completed, the CLI will output your public Gateway endpoint URL: https://hoox.alpha-trading.workers.dev
Step 4: Verify the Deployment
Run the health check to confirm everything is online:
hoox check health
You should see all enabled workers reporting healthy status. To fix any issues automatically:
hoox check health --fix
Step 5: Fire a Simulated Trade Webhook
Now, fire a test webhook trade signal to your live gateway using curl.
curl -X POST https://hoox.alpha-trading.workers.dev/webhook \
-H "Content-Type: application/json" \
-d '{
"apiKey": "your-hoox-webhook-passkey",
"exchange": "bybit",
"action": "LONG",
"symbol": "BTCUSDT",
"quantity": 0.001,
"leverage": 10
}'
Step 6 (Optional): Measure Fast-Path Latency
Once live, you can probe the deployed system to measure end-to-end latency:
# Send 50 synthetic probes and report p50/p95/p99 per-hop latency
hoox perf fastpath run --n 50
This reports per-hop latency for hoox, trade-worker, and analytics-worker so you can identify bottlenecks.
Webhook Payload Parameters Spec
Every webhook payload fired to your Gateway must match the following JSON Schema:
| Parameter | Type | Required | Description |
|---|---|---|---|
apiKey | string | Yes | Your custom webhook authorization passkey (defined in CONFIG_KV). |
exchange | string | Yes | Target exchange router: binance, bybit, or mexc. |
action | string | Yes | Trading action direction: LONG (buy/open), SHORT (sell/open), or CLOSE (flatten position). |
symbol | string | Yes | Standard market symbol. |
quantity | number | Yes | Position size / quantity. |
leverage | number | No | Leverage coefficient. Defaults to 1 (spot) if omitted. |
Expected Success Response
When a signal arrives, the Hoox Gateway authorizes the request, locks execution via Durable Objects, routes order calculations to the edge node nearest to Bybit's servers, executes the order, and registers the transaction in your D1 SQLite table.
You will receive an instantaneous, low-latency JSON response:
{
"success": true,
"requestId": "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d",
"exchange": "bybit",
"symbol": "BTCUSDT",
"action": "LONG",
"result": {
"orderId": "18049284739",
"status": "Filled",
"executedQty": 0.001,
"price": 68425.5,
"timestamp": 1779261050000
}
}
Tip
If the exchange is temporarily undergoing system maintenance or experiences
high network congestion, Hoox will automatically intercept the failure,
enqueue the trade in Cloudflare Queues with exponential backoff retry
policies, and return a "status": "Enqueued" response to guarantee delivery!
Next Steps
- How Hoox Works — Take a deep dive into the edge processing pipelines.
- Terminal UI Guide — Run, hot-reload, and inspect live metrics in a full-screen console interface.
- Set Up Telegram Alerts — Link your bot to get order fills pushed straight to your phone.