Security
Know who you are trusting.
Your group controls the server. That removes a central platform from the conversation, but it makes the friend operating the host part of the trust boundary.
The plain-language promise
- Your server stores messages, identity records, settings, and uploaded files.
- Voice, video, and screen media pass through the server while people are connected; snug does not record them.
- License checks do not include conversations, member identities, or usage analytics.
- The host operator can access the machine and its stored data. Choose someone the group trusts.
Encrypted in transit
Chat and signaling use HTTPS and secure WebSockets through Caddy. Browsers encrypt voice, video, and screen sharing with WebRTC’s DTLS-SRTP transport.
If an admin enables the optional shared server password, a new member sends it over this HTTPS connection. Do not share or use that password through a bare HTTP address.
This protects traffic between each person and your server. It does not make the server invisible or untrusted.
Simple data at rest
Durable data is one SQLite database and one uploads directory on the disk you control. Enable full-disk encryption through the host or VPS provider, restrict SSH access, and keep encrypted off-host backups.
Voice, video, and screen media are forwarded from memory and are not written into the database or uploads directory.
An optional shared server password is stored only as an independently salted, deliberately expensive verifier. The plaintext password cannot be viewed later.
Why snug does not claim end-to-end encryption
snug is not end-to-end encrypted. The server must deliver the web application, store messages, and relay live media. An operator with control of a running host can change that application or inspect its data.
For a small friend group, the useful boundary is concrete: the server belongs to one of you, members do not need snug accounts, and the software does not copy the conversation elsewhere.
What leaves the server
About once a month, the server asks snug to validate its signed license. That check prevents one license from being copied across communities. It does not include messages, files, call media, member identities, or usage analytics.
If the licensing service is unavailable, the server honors its local license and tries again later. Link previews are separate: the server fetches a page when a member posts its address. Optional GIF searches go from the member's browser to the provider chosen by the operator.
Every member gets a footer action for sending written feedback. That note goes to snug’s first-party receiver by default and its temporary local copy is removed after receipt. Failed delivery and diagnostics remain in the community server's admin-only inbox; diagnostics leave only when an admin sends one. The receiving route is enabled only by an explicit first-party server setting, and support payloads omit the server address, IP, member identity, messages, files, and credentials.
Access stays inside the room model
The first identity is the founder and initial admin. Smaller powers are delegated through roles. Private channels are enforced on the server for history, search, typing, unreads, and voice occupancy. They are not merely hidden by the browser.
There are no per-member passwords. A device keeps an identity secret locally; another device joins that identity through a short-lived, single-use code. An admin may set one lightweight shared password for creating new identities at the community's separately shared address, but changing it never alters those existing credentials or bot tokens. An unlisted address reduces casual discovery but is not itself a secret. A host-only recovery command can restore admin access without creating a duplicate person.
Operator checklist
- Use key-based SSH and remove unused accounts.
- Enable full-disk encryption and automatic security updates.
- Expose only the documented web and media ports.
- If you use the shared server password, share it outside snug and rotate it when it is exposed.
- Keep the server package current and read release notes before upgrading.
- Back up SQLite and uploads together to a different system.
- Test recovery before the group depends on the room.
Ready to bring up a room?
Start with hosting →