Deployment models
There are exactly three. They differ in who runs the server and how much of us you depend on — never in what we can see.
The three models
| Model | Who runs the daemon | Depends on our services | Owns message data |
|---|---|---|---|
| Stand-alone | You | Nothing at all | You |
| Self-hosted federated | You | Opt-in, per function | You |
| Hosted | Us, on your behalf | All of them, operated for you | You |
The invariant across all three. A federated service brokers identity, notification, discovery, and provisioning metadata only. No OpenChime-operated service is ever in the message path, and none can read message content, in any model — including the one where we own the hardware.
That is what makes federation safe to opt into: a federated self-hoster gives up no data sovereignty relative to a stand-alone one — only independence of availability.
1. Self-hosted stand-alone
You run the daemon and depend on no OpenChime service at runtime.
Local accounts managed by the daemon, your own domain and DNS, your own object storage. There is no license check, no telemetry, and no callback — the daemon never fetches its configuration from a control plane in any model, so this one has no runtime dependency on the project whatsoever. It will run on a network with no route to the internet.
The trade is that federated-only features are simply absent. Most visibly, mobile push is unavailable in this model — the published mobile clients are signed under the project's developer accounts, so push cannot be delivered without the project's gateway.
2. Self-hosted federated
You still run the daemon and own all message data, but opt in to the services that are impractical to run yourself.
Each of the six is independently declinable. Decline all of them and you have model 1 exactly. They are free — this is not a paid tier.
- Single sign-on
-
We act as the relying party against your identity provider and re-issue a short-lived token scoped to your workspace.
If you decline it: Use local accounts managed by the daemon instead. - Mobile push delivery
-
A contentless relay that wakes iOS and Android devices through Apple and Google.
If you decline it: No mobile push. The published mobile clients are signed under the project's developer accounts, so nobody else can deliver to them. - App directory
-
The catalog of integrations your workspace can wire up.
If you decline it: Configure incoming webhooks by hand — the connections are local to your server either way. - SCIM provisioning
-
Accounts created and deactivated automatically from your identity provider.
If you decline it: Manage membership in the workspace directly. - DNS name and workspace registry
-
An optional address under our service suffix, plus registration of your opaque workspace id.
If you decline it: Bring your own domain and DNS. - Package distribution
-
Signed builds published for installation and update.
If you decline it: Build from source.
Federated is not the same as in-path. A DNS record or a signed package repository is something the project provides, but neither serves requests in your workspace's traffic. And if our services are unreachable, a federated deployment keeps serving messages normally — you lose sign-on and push, not the message path.
3. Hosted
We operate the daemon and the federated services on your behalf.
Architecturally this is model 2 plus operating the box. It is the same binary with the same per-tenant isolation — we did not build a separate multi-tenant edition for paying customers, because there isn't one.
You are buying operations: provisioning, patching, and being the one who gets paged. See hosted for what that includes and pricing for what it costs.
One box, one database, per workspace
In all three models a workspace is one daemon with one SQLite database on one box — the island model. No workspace's data shares a process or a database with another's, and that holds regardless of which federated services a deployment opts into, because none of them are in the data path.
A practical consequence: hosted cost is driven by concurrent load and data volume rather than by how many people you have registered.
Telling the daemon which model it's in
OPENCHIME_DEPLOYMENT_MODE takes
standalone, federated, or managed,
and is reported to clients so they can show it. Setting it does not by
itself switch anything on — each federated service is gated on its own
configuration, so a deployment only reaches out to what you have
explicitly pointed it at.
Pick a model
Two of the three are free. The third is $99 a month and runs the same software.