Encrypted transport
ZChat supports encrypted chat traffic between visitors, operators, and your server. Because the product is self-hosted, certificate ownership and HTTPS configuration stay aligned with the rest of your infrastructure rather than being hidden behind a hosted platform.
Protect visitor and operator traffic with the same encrypted transport standards you already use elsewhere.
Use corporate PKI, commercial certificates, or automated issuance workflows that match your environment.
Deploy with IIS, Kestrel, reverse proxies, or containerized setups while keeping traffic encrypted end to end.
Once HTTPS is configured in your hosting environment, ZChat uses secure transport for chat communication and real-time messaging.
On a hosted platform the certificate belongs to the vendor and the chat traffic crosses their infrastructure. Self-hosting moves both back to you - which also means the configuration is yours to get right.
Page traffic runs over HTTPS and the realtime channel upgrades to a secure WebSocket on the same origin, with an automatic fallback to secure polling on networks that block WebSockets - corporate proxies included.
Use an internal CA, a commercial certificate, or automated issuance. Nothing about the trust chain is delegated to a chat vendor, and renewals follow whatever process the rest of your estate already uses.
Terminating TLS at IIS, Nginx or a CDN and forwarding to the application is a normal arrangement. Preserve the original host and scheme at the proxy, and set the application's public URL to the https address visitors actually use, so generated links and the widget origin agree.
A browser blocks an insecure script on a secure page. Point the embed at your https origin and the widget, its API calls and the realtime connection all follow - which is why the embed takes an explicit server URL rather than guessing.
Yes. Chat traffic runs over HTTPS, and the realtime connection upgrades to a secure WebSocket on the same origin. Because you host it, the certificate is yours - corporate PKI, a commercial certificate, or automated issuance all work.
Yes. A browser blocks an insecure script on a secure page, so an HTTPS site must load the widget from an HTTPS server address. Point the embed's server URL at your https origin and the realtime connection follows automatically.
That is a common deployment. Terminate at IIS, Nginx or your CDN and forward to the application. Configure your proxy to preserve the original host and scheme, and set the application's public URL to the https address your visitors use, so generated links and the widget's origin match.
Include the scheme in the App Site URL - type https://your-server (or http:// for a plain-HTTP test server) and the console connects accordingly. Only a bare host name falls back to the 'use secure connection' option in Options.
Every response carries a strict Content-Security-Policy plus X-Content-Type-Options, X-Frame-Options, Referrer-Policy and X-Permitted-Cross-Domain-Policies. Visitor-facing endpoints are rate limited per IP, and webhooks can be HMAC-SHA256 signed so a receiver can verify they came from you.
ZChat gives you the installable server, web dashboard, website widget, and desktop agent tools in one self-hosted product you buy once and keep. Run it on infrastructure you trust and connect AI only if and how you want it.
Deployment
Install on Windows or Linux, behind IIS or Nginx, in a VM, or in Docker if that fits your stack.
Commercial model
One-time purchase, perpetual license, and no monthly per-agent bill attached to growth.
AI Flexibility
Use Ollama locally or connect OpenAI and Anthropic with your own provider accounts.