Skip to main content

Cloud vs Self-Hosted Parity Matrix

The design commitment: the self-hosted knoxcall/proxy Docker image is the same binary KnoxCall Cloud runs at *.knoxcall.com. The router logic, the secret-injection engine, the rate limits, the audit log, the alert monitor — identical code. Where behaviour diverges it’s because the underlying resource is only available in one mode, and we document each exception here.

Quick Summary

You can pull this as a live JSON document from GET /admin/parity-audit — the admin UI renders it under Settings → Deployment → Feature parity.

Routing & Transformation

Security

Analytics & Alerts

Integrations

Lifecycle

What “Same binary” Actually Means

  • We build one Docker image per release: knoxcall/proxy:{version}.
  • That image runs on our servers at knoxcall.com AND on your self-hosted infrastructure.
  • The only difference is environment configuration: KNOXCALL_DEPLOYMENT_MODE=cloud | self_hosted, which tenant it serves, and which external credentials it’s given.
  • No forked codebase, no “Enterprise Edition”, no minus-features stripped out. When we ship a new feature on cloud, it arrives in the next self-hosted image pull.

Self-Hosted is Not a Subset

A common worry: “self-hosted versions of SaaS products are always stripped down.” That’s not our model. Self-hosted has more required configuration (you bring your own SMTP, Redis, Postgres, MaxMind, etc.) but the runtime behaviour is identical. What the customer loses in self-hosted is:
  • The cloud operator doing ops for you — you back up your own Postgres, rotate your own secrets, watch your own alerts. We still push the control-plane config (routes, secrets, feature flags) but the data plane is yours to operate.
  • Cross-tenant features we haven’t yet made portable — Stripe billing, KnoxCall-branded egress IPs, the global AI anomaly model trained across tenants. These stay cloud-only.
Everything else ships identical between the two.

How We Enforce Parity

Three mechanisms:
  1. Source identity. Both modes compile from the same src/. CI rebuilds the image on every merge.
  2. Shadow testing during migration. The migration wizard dual-sends real requests through both sides and diffs responses before letting you cut over.
  3. This document. Every known divergence is listed. If you find a feature that behaves differently and isn’t in the Cloud-only row, that’s a bug — email us.
See also: Self-hosted proxy guide, Migration guide, Agent security model.