Data residency and regulatory control
Use self-hosted deployment when visitor conversations cannot leave a specific jurisdiction or must remain on infrastructure your organization controls directly.
When residency requirements, air-gapped networks, internal-only deployments, or strict compliance boundaries take hosted chat off the table, Zchat runs the same Dchat platform on your own infrastructure.
Most teams are fine on Dchat cloud. These are the situations where self-hosted is the requirement, not just a preference.
Use self-hosted deployment when visitor conversations cannot leave a specific jurisdiction or must remain on infrastructure your organization controls directly.
For teams with strict compliance, internal-only environments, or procurement rules that limit third-party SaaS, self-hosting keeps the support stack inside your boundary.
Zchat works with OpenAI-compatible endpoints, including private or local model infrastructure, which makes it practical for air-gapped or highly restricted networks.
For very high-volume workloads, self-hosting can make more economic sense than ongoing SaaS expansion because the operating model shifts toward infrastructure you already control.
Zchat ships the same codebase that runs Dchat cloud. You do not trade product direction for deployment control.
AI-first replies, same-thread human handoff, knowledge base, URL import, site crawl, proactive triggers, canned responses, routing, and branded widget controls.
Visitor conversations, contacts, and knowledge content stay on infrastructure you control directly.
OpenAI, Anthropic, Azure OpenAI, or any OpenAI-compatible endpoint, including local model infrastructure for private deployments.
Bring your own certificates, run on your subdomains, and keep the widget loading from infrastructure you control.
Standard ASP.NET Core deployment on IIS, Nginx, or Kestrel with a familiar operational model for teams already running .NET infrastructure.
Self-hosted buyers can pair the product with support and update arrangements that fit internal operations and release management needs.
Same product underneath, different operating models. Most teams start on cloud and only move if specific constraints appear.
| Decision factor | Dchat cloud | Zchat self-hosted |
|---|---|---|
| Setup time | Minutes | Longer rollout |
| Infrastructure management | Dchat runs it | Your team runs it |
| Where visitor data lives | Cloud-managed | Your servers |
| Residency control | Provider-managed | Your environment |
| Private or local model support | Not the default path | Yes |
| Best fit | Most SMB and mid-market teams | Regulated, private, or infrastructure-controlled environments |
Same codebase. Dchat is the managed cloud service. Zchat is the self-hosted distribution you install and run on your own infrastructure.
Yes. The product direction is aligned specifically so teams can move from managed cloud to self-hosted when the operating requirements change.
A standard ASP.NET Core hosting environment, database infrastructure, TLS certificates, and an AI provider endpoint. The exact deployment shape depends on your environment and control requirements.
Yes. Zchat is designed for OpenAI-compatible endpoints, which makes private or local model infrastructure practical for restricted deployments.
Self-hosted buyers should contact the team directly for deployment, licensing, and support details that match their environment.
Yes. Zchat follows the same product direction as Dchat cloud, with a release model suited to self-hosted operations.
Zchat ships the same product direction Dchat cloud runs, but on infrastructure you control, in the jurisdiction you choose, with the AI provider setup that fits your environment.