Managed Chatwoot Hosting: What You Hand Over and Keep (2026)

I lead ERPNext, Frappe and open-source deployments at MithTech, and Chatwoot is a support inbox we often set up next to an ERP. Teams rarely struggle to install it. They struggle a year later, when nobody remembers who applies the upgrades or whether the last backup ever restored.

What does managed Chatwoot hosting actually cover?

It covers the jobs that come with the server, not the work of answering customers. Chatwoot's Docker guide runs a Rails web process on port 3000 and a Sidekiq worker for background jobs, next to Postgres and Redis. The containers bind only to localhost, so a reverse proxy such as Nginx, with a Let's Encrypt certificate, publishes the inbox to the internet.

Each part is a job somebody must own:

• The server and its processes. Rails and Sidekiq running, Postgres and Redis healthy, enough disk for attachments.
• File storage. Chatwoot stores attachments on the server's local disk by default. Its docs suggest cloud storage such as Amazon S3 so attachments are backed up properly.
• The certificate and proxy. Renewals, and the Nginx settings Chatwoot needs, such as allowing underscores in headers.
• Upgrades. Chatwoot ships releases often; v4.19.1 was the current one when we checked. After each Docker upgrade the database preparation task must run, and very old installs should step through intermediate versions.
• Backups and restores. The database, the attachments and the secrets, copied off the server and tested.
• Watching it. Someone notices when the inbox stops receiving messages before a customer does.

The work of running your support team stays with you: inboxes, agents, canned replies, automations and reports.

What do you hand over, and what do you keep?

You hand over access to the server and the work on it. You keep everything that would be painful to rebuild, and everything that proves the setup is yours.

The channel accounts matter most. A WhatsApp inbox in Chatwoot connects through a Meta app and a WhatsApp Business account, with an app ID, configuration ID and app secret set by a super admin. Make sure those accounts are registered to your company, not to whoever set the inbox up. The same goes for the support mailbox and the domain.

Self-hosted, Chatwoot Cloud or run for you: how do they compare?

All three are fair choices. They differ in who does the server work and where the data sits.

Chatwoot Cloud is the simplest path for a small team. There is no server to think about, and its plans and current prices are on Chatwoot's pricing page. Choose it if your customers and contracts are happy with data held in the United States.

Self-hosting suits a team with someone who knows Docker, Postgres and Nginx and has the hours. Chatwoot's self-hosted plans page lists a free community edition, and paid editions that add features such as SSO and SAML and support from Chatwoot. You run the server in every case. The full setup, with Docker Compose or Coolify, is in our guide to Chatwoot self-hosted.

Run for you suits a team that wants the data on a server it chooses but has nobody to own the server. If you are still weighing Chatwoot against hosted helpdesks, start with Chatwoot vs Intercom vs Zendesk and the open-source Zendesk alternative.

What should a managed host put in writing?

The agreement should answer five questions before you move a single conversation:

1. Backups. How often they run, where the copies go, and how often one is restored to prove it works.
2. Upgrades. Whether each release is tried on a copy first, and how you are told before it runs.
3. Logins. Who holds root, the super-admin login and the API tokens, and how you get the list.
4. Response time. How fast someone acts when the inbox breaks, stated in the agreement itself, not in a sales line.
5. The way out. What you receive if you leave, and in what form.

If a host cannot answer one of these in writing, treat that as the answer. The same questions apply to any system you hand over; for an ERP they are set out in who runs ERPNext after go-live.

How do you leave a managed Chatwoot setup?

You leave with three things: a Postgres dump, the attachments, and the .env file. The dump holds the conversations, contacts and settings. The attachments sit on the server's storage volume, or in the object storage bucket if Chatwoot was set up that way. The .env file holds SECRET_KEY_BASE and the other secrets, which a restored database needs to work.

The steps are the same as the backup routine in our Chatwoot self-hosted guide. Restore them on the new server, run the database preparation task, point the domain at it and check the inboxes reconnect. Leaving Chatwoot Cloud is a different route: its pricing page says data can be exported through the API.

Should you run Chatwoot yourself, or have it run for you?

Run it yourself if someone on your team will apply Chatwoot's releases, keep backups off the server and test a restore. Choose Chatwoot Cloud if you want no server at all and United States hosting suits you. Have it run for you if the data must sit on a server you choose and nobody owns that work.

Under managed hosting we run Chatwoot on one named server in your cloud account or ours, not a shared pool. Backups run nightly and are copied off the server, and one is restored on a schedule. Every upgrade is tried on a copy first, and the keys and the master login stay yours. We pick the region with you; an Indian region is the usual choice for Indian companies, with backups going to a second location you approve. It is a monthly fee for running it plus the server, quoted in writing after a call. If you leave and it runs in your account, the server is already yours; on ours, you get a full backup, the code and the settings. The self-hosting cost comparator sets that against the other two paths.

Frequently asked questions