Questions & answers

A private, real-time team chat you run entirely on your own server — messaging, calls, files and an admin panel, with nothing sent to third-party services.

No. Messages, files and accounts live only on your server. The only optional outbound connections are your own SMTP server, Let’s Encrypt (if you use a domain certificate), and browser push services (only if users enable notifications).

Yes, after installation. Setup needs internet to fetch Node.js; afterwards it runs on an isolated LAN.

A small VPS comfortably serves a typical team. It uses the SQLite engine built into Node.js — no separate database server to run.

Nothing on our side sits in the path of your messages, so our uptime is not something you need to watch. Chatstead runs entirely on your server: no cloud relay, no third-party push service, and licences are signed keys verified offline — there is no activation server to phone home to. Your installation keeps working even if our website disappeared tomorrow, and you keep the source code you bought. What is worth monitoring is your own server, which is what the health endpoint below is for.

Yes — a native Android app is included in the download as a signed APK, ready to install. It is one generic app: each user simply types the address of your server when signing in, so you do not need a separate build per site. On iPhone and desktop, Chatstead installs as a PWA from the browser (Add to Home Screen).

Yes. There is no push service in a self-hosted product — no Firebase, no relay — so the app keeps the connection to your own server through a background service. That is why Android shows a permanent low-priority “Connected” entry in the notification drawer; it is the price of not routing your messages through anyone else. Allow the battery-optimisation exemption the app asks for, and on Xiaomi/Huawei phones also enable Autostart, otherwise the manufacturer’s battery manager can kill the service.

Yes. The full Android project is part of the package, along with instructions for changing the name, icon, package id and signing key, so you can build and distribute your own branded app (see docs/ANDROID.md and your licence terms). Nothing in the app talks to us.

Android 7.0 and newer. The app is distributed as an APK you install directly — no app store account is involved. Note that a self-signed certificate is rejected by Android, so use a real domain with a trusted certificate, or connect over plain HTTP inside your local network.

No. You copy one command onto a fresh Ubuntu server, then finish setup in your browser with a friendly wizard.

No — a sudo-enabled user works fine. Installing a system service does need elevated privileges, so keep the sudo in the commands.

Point a domain at your server and the installer provisions a free, auto-renewing Let’s Encrypt certificate via Caddy. See the Docs for the two ways to set up a domain.

Yes — the package ships a Dockerfile and two compose files: one that runs Chatstead behind Caddy with an automatic Let’s Encrypt certificate (set your domain and start it), and one for a self-signed certificate when you have no domain.

Yes. Beyond encrypting passwords and messages, browsers refuse to give the microphone, camera, app-install and notification permissions to a page that isn’t on HTTPS. Without it, voice messages, calls, “Add to Home Screen” and push notifications don’t show an error — they simply never appear, and it looks like the product is broken. Chatstead always enables TLS; you only choose which certificate.

Both encrypt the connection exactly the same way. A trusted certificate (free, from Let’s Encrypt) is vouched for by an authority browsers already know, so there’s no warning — but it needs a domain name. A self-signed certificate is one your server issues to itself: it works on a bare IP, but every browser warns once per device because nobody outside confirmed the server’s identity.

Ask whether people will use it from outside your office. If yes, get a domain and a trusted certificate — that’s the only setup where phones on mobile data, remote staff, app install and push notifications all work cleanly. If it stays on the office network, self-signed is a sensible trade-off: the traffic never leaves your building.

The encryption is exactly as strong. The warning means no outside authority vouched for the server’s identity — which matters on the open internet, where you can’t be certain what you’ve connected to, and much less on a network you control and a machine you know.

Yes, at any time and without reinstalling. Run the installer again with your domain and it switches to a trusted certificate; your data and accounts are untouched.

With a domain: 80 and 443 — port 80 is how Let’s Encrypt confirms you own the domain, and it redirects visitors to HTTPS. Without a domain: 3443. Don’t forget your provider’s external firewall (Hetzner Cloud Firewall, AWS security groups and so on) — it’s separate from the server’s own firewall.

It’s plain, unencrypted HTTP, and it exists only because the native mobile apps reject self-signed certificates. Never expose it to the internet — anything sent over it, passwords included, is readable along the way. Keep it on your local network; in Docker it’s bound to localhost by default for that reason.

Yes. Let your proxy keep handling certificates and run Chatstead with NO_HTTPS=1 and PORT=8080, then set TRUST_PROXY to the proxy’s address or network so audit entries and rate limits see the real visitor rather than the proxy. The proxy needs to forward WebSocket upgrades.

Self-registration is off by default for security. Sign in as admin → Registration & Security → enable “Allow users to register themselves”, and a Register link appears. Or add users manually from the admin panel.

Either an admin creates them, or you enable self-registration and people sign up themselves (with captcha, and optional email verification / admin approval).

Yes — set your name, logo and icon in the admin panel. Changes apply instantly, no code needed.

Ask another admin to reset it. Keep backups so you can always recover.

In a data folder on your server (database, keys, certificate, branding) plus an uploads folder for files. Back both up.

Upload the new release and re-run the installer — data is preserved and the schema migrates automatically. Back up first.

Yes, a daily backup script is included and can be scheduled with cron.

Every installation exposes GET /api/health, which returns the status, version, uptime, whether setup is complete and whether the instance is licensed. It reports “degraded” if the database stops answering, so it is a real health check rather than a port test. Point any monitoring tool at it — UptimeRobot, Uptime Kuma, Zabbix, Datadog or a script of your own.