Chatto Turns Self-Hosting Team Chat into an Open-Source Default

The moment you realize “free” chat has a cost

Picture this: you’re part of a team chat, you’re building momentum, and you’re sharing ideas faster than anyone can document them. Then the quiet worry creeps in—Where does this data live? Who can access it? What happens when someone leaves? That worry isn’t paranoia; it’s the natural reaction to centralized services that optimize for growth, not control.

That’s where open source apps like Chatto land differently. Chatto is a group/team chat application designed to be self-hosted, meaning the software runs on your infrastructure (a server you control), instead of being hosted by a third party. Chatto’s announcement also makes a big promise: compact deployment, privacy-first storage, and encrypted voice and video calls—all under an open license. (hmans.dev)

“Open source” isn’t a buzzword—it changes your threat model

Before code and commands, it helps to clarify the term. Open source means the software’s source code is available publicly, so anyone can audit it, build it, or run it in their own environment. That matters for chat because the “trust” question is usually the whole game.

When you self-host, you shift responsibility in a practical way: you manage uptime, upgrades, and security hardening. But you also gain control over privacy boundaries, because your server is the system that stores and serves the data. Chatto positions itself as “your chat, your rules,” with features aimed at reducing tracking and tightening how data is handled at rest. (hmans.dev)

Spinning up Chatto locally: the smallest path to “it works”

A surprising amount of self-hosting pain comes from dependency hell: databases, caches, message brokers, and a dozen configuration files. Chatto’s setup flow is designed to minimize that friction by packaging the server as a small standalone executable.

On macOS, the announcement points to Homebrew as the quickest path:

brew install chattocorp/tap/chatto
chatto init
chatto run

Let’s translate what those three commands mean in plain language:

• brew install ... downloads and installs the Chatto client/server binary onto your machine.
• chatto init creates initial configuration (and typically scaffolding for the server’s data).
• chatto run starts the server process, so clients can connect.

This is the “developer” version of convenience: instead of building a whole platform, you start with a single command and let the app guide the rest. (hmans.dev)

What “encryption at rest with per-user keys” really implies

Security language gets thrown around so often that it can blur into marketing. So let’s pin it down.

Encryption at rest means data stored on disk is encrypted (not readable as plain text). Per-user keys means the encryption keys are tied to individual users rather than one shared master key for everyone.

Chatto describes fully encrypted storage with per-user keys, plus “crypto shredding” when a user deletes their account. (hmans.dev)

Why should a beginner care about “keys” and “shredding”? Because the key concept is deletion properties:

• With a shared key model, deleting a user can be tricky—you might delete records, but the decrypting power still exists for whatever is left.
• With per-user keys, you can make deletion cryptographically meaningful, because the data is only recoverable if the relevant keys still exist.

In real-world deployments, encryption is only as strong as key management and operational discipline. But as a design direction, per-user keys are a serious step toward aligning system behavior with the privacy promise.

A question-shaped thought many people search:

How can a chat app delete someone’s messages in a way you can actually trust? Chatto’s per-user key approach is aimed at making that question answerable at the storage layer. (hmans.dev)

One server, one community: a simpler privacy boundary

Another architectural choice matters more than it sounds: Chatto’s model is “one community per server,” with no federation between servers.

That means:

• A single Chatto server is meant to host one community’s data.
• There’s no automatic mixing or syncing of user/message data across servers.
• If you want to participate in multiple communities, the client can connect to multiple servers directly.

This is the opposite of systems that treat servers as peers in a federated network. Federations can be great for resilience and discovery, but they can blur data boundaries. Chatto’s approach makes the privacy story more legible: server A holds server A’s data. (hmans.dev)

Calls built in: end-to-end encrypted voice/video with screen sharing

Most chat systems separate “messaging” from “calls,” and that separation often drifts into relying on third-party real-time services. Chatto frames voice and video as first-class features with built-in screen sharing.

It also claims calls are fully end-to-end encrypted (E2EE). End-to-end encrypted means only the communicating endpoints (the participants) can decrypt the media; the server relays encrypted streams rather than seeing plaintext content.

From an engineering perspective, E2EE for real-time audio/video is hard because media has to be encrypted fast enough for low latency, and because key exchange must work reliably over unstable networks. Chatto’s value proposition here is practical: you shouldn’t need to stitch together extra products to get privacy-preserving calls. (hmans.dev)

Licensing: why AGPL matters even for “private” use

Chatto’s GitHub repository indicates it’s licensed under AGPL-3.0-or-later by default, with Apache-2.0 exceptions for certain areas like standalone frontend/integration surfaces and documentation. (github.com)

For beginners, the key idea is this: AGPL (Affero GPL) is designed for networked applications. If you modify and run AGPL software as a service, the license is structured to require making source available to users interacting with it over the network.

That doesn’t mean “you can’t run it”—it means open-source compliance has teeth for hosted software. If you’re deploying Chatto internally, the licensing still matters because tweaks and integrations can trigger obligations.

Stability and versioning: expect movement at version 0.x

Chatto’s announcement states the project is at version 0.4 and is considered stable enough for production, while still missing features and evolving quickly. (hmans.dev)

Version 0.x releases usually signal two things:

1. There may still be breaking changes.
2. The project is still converging on “final” behavior and API surfaces.

That’s not a deal-breaker; it’s part of the reality of fast-moving open-source teams. The operational takeaway is to treat upgrades like you would any other production software: plan for testing, schedule rollouts, and keep backups.

Chatto Cloud: the hosted option without the lock-in vibe

Not everyone wants to run chat infrastructure. Chatto also introduces Chatto Cloud for paid hosting in a public beta, describing it as hosting-only (no premium tiers, no ads) and emphasizing compatibility with self-hosted servers. (hmans.dev)

Chatto Cloud is described as launching with European and European-owned infrastructure, plus features like automatic scaling, nightly backups, and zero-downtime upgrades. (hmans.dev)

The practical appeal is clarity: if you can tolerate a managed service, you offload maintenance work while keeping the option to move. In other words, the goal is not “rent the app forever,” but “choose where to run it.” (hmans.dev)

The bigger story: nicer self-hosted chat, end-to-end where it counts

Chatto’s open-source release is more than a licensing switch—it’s a statement about what team chat should feel like when you control your data. The experience targets the parts that usually frustrate people: lightweight deployment, privacy-first storage with encrypted data and user-scoped keys, and built-in encrypted voice/video calls.

Whether you start by running a single executable or plan to adopt Chatto Cloud later, the core design theme stays consistent: own your conversations without giving up modern features.