> ## Documentation Index
> Fetch the complete documentation index at: https://docs.knoxcall.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Deployment Modes

> Choose between KnoxCall Cloud (managed) and self-hosted Docker, and between direct DNS routing or the Go Agent for zero-code-change onboarding.

# Deployment Modes

KnoxCall runs the same binary in our cloud and on your infrastructure. You choose **where the data plane lives** and **how your app reaches it** — two independent decisions, each with a sensible default.

## The 2×2 Matrix

|                                             | **Direct URL / DNS** (code or DNS change) | **Via Go Client Agent** (no code change) |
| ------------------------------------------- | ----------------------------------------- | ---------------------------------------- |
| **KnoxCall Cloud proxy** (managed, default) | Combo 1 — easiest                         | Combo 2 — no code change                 |
| **Self-hosted `knoxcall/proxy` container**  | Combo 3 — data-residency                  | Combo 4 — both                           |

Most customers start on **Combo 1** (KnoxCall Cloud + Direct). Upgrade to the Go Agent when changing base URLs is impractical. Move to self-hosted when regulation requires API payloads to stay on your infrastructure.

## Decision Tree

1. **Does regulation require API payloads to never leave your network?**
   → Yes: [Self-hosted proxy](/infrastructure/self-hosted-proxy)

2. **Can your app change its base URL or DNS records?**
   → Yes: direct routing (see [Getting Started](/getting-started/first-route))

3. **Otherwise** → [Install the Go Agent](/infrastructure/go-agent)

## Where Secrets Decrypt

This is the key differentiator between cloud and self-hosted:

* **KnoxCall Cloud mode**: your secrets are decrypted on our servers at request time. This is fine for 99% of customers — we never log plaintext and each secret is envelope-encrypted with a per-row key under our MASTER\_KEY\_B64.
* **Self-hosted mode**: your secrets decrypt on *your* infrastructure. The cloud control plane only holds them in their re-encrypted form (wrapped with a session key rotated hourly). No plaintext secret ever leaves your VPC in this mode.

## Control Plane vs Data Plane

Regardless of mode, the **control plane** — the admin UI, route definitions, secret storage, billing, analytics — always lives at knoxcall.com. What varies is the **data plane**: the service that handles your live API traffic.

```text theme={"dark"}
┌────────────────────────┐      ┌───────────────────────────┐
│  Control plane         │      │  Data plane               │
│  (always knoxcall.com) │ <──→ │  (cloud OR customer-run)  │
│  Admin UI, routes,     │      │  Handles live API traffic │
│  secrets (encrypted)   │      │                            │
└────────────────────────┘      └───────────────────────────┘
```

In cloud mode, the data plane runs on our infrastructure at `{tenant}.knoxcall.com`. In self-hosted mode, you run the same `knoxcall/proxy` Docker image on your infrastructure — the control plane still holds config and pushes it down via short-lived [session bundles](/infrastructure/self-hosted-proxy#session-bundles) every hour.

## Pricing

| Plan       | Cloud (default) | Self-hosted option | Go Agent option |
| ---------- | --------------- | ------------------ | --------------- |
| Free       | ✅               | —                  | —               |
| Starter    | ✅               | —                  | —               |
| Pro        | ✅               | —                  | —               |
| Enterprise | ✅               | ✅                  | ✅               |

Self-hosted and the Go Agent are gated by the existing `byoAgentEnabled` feature flag, available on Enterprise only.

## Next Steps

* Install the [Go Client Agent](/infrastructure/go-agent) for zero-code-change onboarding
* Run the [Self-hosted proxy](/infrastructure/self-hosted-proxy) on your own Docker infrastructure
* Plan a [Cloud → Self-hosted migration](/infrastructure/migration) with shadow-mode testing