"Can we self-host it?" is usually asked late, after a team has already started using a cloud tool. The answer changes more than the deployment diagram.
1. Backups become your problem, and that is the point
In a hosted product, backups are a line in a contract. Self-hosted, they are a cron job, an off-site copy, and a restore you have actually tested. Teams that skip the restore test discover the problem at the worst moment.
The upside: the backup never leaves infrastructure you control, which is often the original reason for self-hosting.
2. Upgrades are a decision, not an event
Cloud products upgrade on the vendor's schedule. Self-hosted, an upgrade is a maintenance window you choose — and can postpone during a busy week. That flexibility is real, and so is the cost: someone has to read the changelog.
A practical rule: pin the image tag, upgrade monthly, keep the previous tag for a one-command rollback.
3. Attachments change the storage question
Conversations carry files. In the cloud, those files sit in someone else's object storage. Self-hosted, they sit on your disk or your S3-compatible bucket, which means retention, quotas and encryption are yours to define — and yours to get wrong.
4. Email is the hard dependency
A support desk that cannot send email is not a support desk. Self-hosting the app is easy; self-hosting reliable outbound email is not. Most teams run the app themselves and still send through a transactional provider. That is a reasonable split: the conversations stay inside, the delivery goes through a specialist.
5. What you actually gain
- A retention policy you can enforce rather than request
- Data residency answered with an IP address instead of a document
- Access control that maps to your own identity provider
- The ability to run on a network with no outbound internet, if that is the requirement
6. What you actually give up
- Vendor-managed uptime
- Someone else testing upgrades before you see them
- Support that assumes they can see your database
A workable middle ground
Run the app in Docker with three services (app, database, queue), a nightly dump to an off-site bucket, and outbound email through a transactional provider. That covers most self-hosting requirements without turning into a platform team.
This is the model Onsites AI ships with: a Docker Compose deployment for the shared inbox, CRM and invoicing, with cloud available for teams that would rather not run it. Free for the first three seats either way.
Top comments (0)