Choose where your API payloads decrypt
KnoxCall runs the same binary in our cloud and on your own infrastructure. You decide where the data plane lives, and how your app talks to it — two decisions, each with a sensible default.
Four paths, two decisions
Where the proxy runs × how your app reaches it. Most customers stay on the top-left; the matrix exists for when you need more.
Point your API client at tenant.knoxcall.com. No code changes beyond a base URL swap. Secrets decrypt on our infrastructure.
Install the Go agent next to your app. It intercepts outbound API calls transparently and routes them through KnoxCall cloud. No base URL change needed.
combo 2 · Pro+Run knoxcall/proxy on your infrastructure. Payloads never leave your network — only routing metadata syncs to the cloud control plane.
Combine the Go agent with a self-hosted proxy. Your apps need no config changes, and payloads still never leave your infrastructure.
combo 4 · Pro+Which one is right for you?
A 10-second walkthrough. Work down the list — the first yes is your answer.
Does regulation require API payloads to never leave your network?
Think HIPAA, GDPR-residency, FedRAMP-adjacent. The whole decrypted request/response path must stay on infrastructure you control.
Yes → Self-hosted (contact sales)Can your app change its base URL or DNS records?
If you can flip a config or CNAME, this is the simplest path. One change, zero agent footprint, runs on every plan including Free.
Yes → Direct URL / DNSOtherwise
Install the Go agent on each host that runs your app. It's a single binary, no code changes, transparently proxies outbound traffic. Pro plan and above.
→ Go AgentCommon questions
Is the self-hosted image the same one KnoxCall runs?
Yes. A single knoxcall/proxy container image powers our cloud fleet and every self-hosted deployment. Features don't drift between modes — if it works in our cloud it works on your infra.
What talks to the KnoxCall cloud in self-hosted mode?
Only the control plane: routes, policy, re-encrypted secrets, metered usage. Every self-hosted container is bound to exactly one tenant and refuses traffic for any other.
Do I bring my own SMTP / Twilio / S3 credentials when self-hosting?
Yes. KnoxCall never pushes its own outbound-integration credentials to a customer container. You configure SMTP, Twilio, Slack, Anthropic, and S3 through the admin UI; they live on your infrastructure only.
Can I switch modes after I start?
Yes, in either direction. A built-in migration wizard supports cloud → self-hosted and back, including shadow-mode diffing before cutover.
Is the Go agent required?
No. The agent is purely a convenience — it lets you adopt KnoxCall without touching app code. Direct URL / DNS routing works on every plan.
How are self-hosted images signed?
Every binary ships with a tamper seal: a two-pass build_sig derived from the binary hash and version. The control plane refuses session bundles to images whose signature it doesn't recognise.
Start where it's easiest
Sign up on Free to try Direct routing in minutes. Upgrade to Pro for the agent or self-hosted options.