[Deploying to Production]

Deploying your algorithmic trading ecosystem to Cloudflare's production edge requires careful orchestration. Because workers communicate internally using fast-path Service Bindings, they have strict compile-time and deploy-time dependencies.

This guide outlines our automated deployment sequence, Next.js OpenNext compilation steps, post-deployment URL bindings, and troubleshooting runbooks.

---

The Strict Deployment Dependency Chain

When you deploy, workers must be uploaded in a specific sequence. If you attempt to deploy the public gateway (hoox) before the database or execution engines are live, the deployment will fail because the gateway's compile-time service bindings cannot resolve their targets.

The Hoox CLI automates this dependency hierarchy:

[1. D1 Database Schema] ──► [2. d1-worker (SQL Hub)] ──► [3. trade-worker (Execution Engine)]
                                                                     │
    ┌───────────────────────────────────────────────────────────────┘
    ▼
[4. hoox Gateway (Public Router)] ──► [5. agent-worker & telegram-worker]
                                                     │
                                                     ▼
                                             [6. Next.js Dashboard (OpenNext)]

Deployment Order Explained

---

Deployment CLI Commands

To execute a complete production rollout:

hoox deploy all --auto

# 2. Deploy a single specific worker (e.g. after a custom logic update)
hoox deploy worker trade-worker

# 3. Redeploy only the dashboard
hoox deploy dashboard

Deploy All Flags

---

Critical Post-Deployment Steps

Once hoox deploy all finishes uploading the workers, you must run three final scripts to link webhooks and sync environment databases:

# A. Register your private Telegram Bot webhook with Cloudflare
hoox deploy telegram-webhook

# B. Auto-update and bind internal Service URLs across all workers
hoox deploy update-internal-urls

# C. Sync and apply the default CONFIG_KV manifest variables
hoox deploy kv-config

Why These Steps Are Required

1. Telegram Webhook Registration — Tells Telegram's Bot API where to send user messages. Without this, your bot will be unreachable.

2. Internal URL Binding — After deployment, each worker gets a new URL. This command updates all Service Binding references so workers can find each other.

3. KV Manifest Sync — Ensures your runtime configuration (kill switch, rate limits, routing rules) matches the freshly deployed workers.

---

Next.js Dashboard Deployment (OpenNext)

The Hoox Command Center is a modern Next.js 16 web application that runs directly on Cloudflare Workers using the OpenNext adapter.

When you run hoox deploy dashboard:

1. The CLI compiles the Next.js app using the Turbopack build engine.

2. The OpenNext compiler bundles the application logic into a single Edge-compliant V8 worker file: .open-next/worker.js.

3. All static files (images, JS chunks, CSS) are isolated under .open-next/assets/.

4. The CLI uses wrangler to deploy the worker and binds the static assets to Cloudflare's ASSETS binding, serving pages at sub-millisecond speeds.

# Build and deploy the Next.js Dashboard to Cloudflare Workers
hoox deploy dashboard

# Rebuild dashboard only (after UI changes)
hoox deploy dashboard --force-rebuild

Dashboard Features

Once deployed, the Command Center provides:

• Real-time portfolio value and P&L tracking
• Win rate statistics and trade history charts
• Live position monitoring with one-click close
• Risk settings adjustment (no redeploy needed)
• AI-powered trade analysis chat

---

Routine Update & Upgrade Workflow

To pull the latest platform releases, run local tests, and update your active production edge:

# 1. Fetch latest changes and update git submodules recursively
git pull --recurse-submodules

# 2. Install updated dependencies
bun install

# 3. Execute the full local CI verification pipeline
hoox test

# 4. Run pre-deploy health check
hoox repair check

# 5. Roll out updates globally to the Cloudflare Edge
hoox deploy all --auto

Rollback Procedure

If the new deployment causes issues:

# 1. Revert git to previous release
git checkout v2.0.0  # or your previous tag

# 2. Redeploy the stable version
hoox deploy all --auto

---

Post-Deployment Troubleshooting Matrix

---

Next Steps

• Real-Time Observability & Monitoring — Audit live fills, tail console logs, and run health diagnostics.
• System Self-Healing & Repair — Rebuild broken bindings and recover from deployment anomalies.
• Infrastructure Management — Provision and inspect KV, Queues, R2, and Vectorize indexes.