Same binary, your choice of where.

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.

Start free Compare plans

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.

Direct URL / DNS
Via Go agent
KnoxCall Cloud
Easiest to tryPoint your client at your tenant hostPoint your API client at tenant.knoxcall.com. No code changes beyond a base URL swap. Secrets decrypt on our infrastructure.All plans
No code changeInstall the agent beside your appInstall the Go agent next to your app. It intercepts outbound API calls transparently and routes them through KnoxCall cloud. No base URL change needed.Pro and above
Self-hosted Docker
Max data residencyRun the proxy on your networkRun knoxcall/proxy on your infrastructure. Payloads never leave your network — only routing metadata syncs to the cloud control plane.Pro and above
Self-hosted, no code changeAgent plus your own proxyCombine the Go agent with a self-hosted proxy. Your apps need no config changes, and payloads still never leave your infrastructure.Pro and above

Which one is right for you?

Work down the list — the first yes is your answer.

  • 1Does 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)
  • 2Can 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 / DNS
  • 3OtherwiseInstall 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 Agent

Common questions.

Six, answered as they are.

  • 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 signature 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.

Start free Compare plans
All systems operational