What stays on your servers
The database, account tokens, conversation history and logs run inside your infrastructure — typically Windows or WSL for small teams. Operational calls still go out to the platform's API; that part cannot be self-hosted.
Self-hosted does not mean 'no vendor'. It means the data and the credentials stay in your environment.
The database, account tokens, conversation history and logs run inside your infrastructure — typically Windows or WSL for small teams. Operational calls still go out to the platform's API; that part cannot be self-hosted.
Upgrades ship as deployment packages plus a service restart, with schema changes handled by a migration script. The trade-off compared with SaaS is that you control when it happens.
Three signals: your data cannot sit with a third party, you need account credentials to stay under your control, or you want the operations to keep running independently of a vendor's uptime.
You can self-host the account fleet and DM handling while keeping a cloud scheduler for broad channels. Most objections to self-hosting are about convenience, not technology.
For a small fleet, no — a single Windows or WSL machine with the deployment package is enough. It is a service, not a cluster.
It removes third-party custody of tokens and conversations. It does not replace account isolation and rate control, which matter either way.
Yes. Data lives in your database, so migrating between deployment models is a data move, not a rewrite.
Self-hosted does not mean 'no vendor'. It means the data and the credentials stay in your environment.