Managed Chatwoot hosting

BusinessOn-prem or sovereign site

One inbox for website chat, email, WhatsApp and social messages, run in Switzerland, the EU or your own datacentre so the conversation history is stored where you chose. Pilae runs it on your own servers, or in Zurich, Switzerland, and eleven other Pilae Cloud regions.

Talk to us about Chatwoot

Licence: MIT
Runs on: Your own hardware, or any of twelve Pilae regions — six of them in Switzerland and the EU
Upgrades: Pinned, tested against your configuration, applied in your window
Upstream: www.chatwoot.com

Running Chatwoot in production: what it takes

Deploy the MIT build
The -ce image at a version we have run, with the web server and the Sidekiq worker in separate containers, PostgreSQL with pgvector, Redis, and attachments in a bucket from the first day. Telemetry to Chatwoot is switched off.
Publish the widget, keep the dashboard private
The gate forwards the widget, help-centre and webhook paths and nothing else. Public sign-up is off, and agents reach the dashboard over the private network.
Connect the channels
Email over IMAP and SMTP where your mail server allows it, so no inbound mail route has to be published. Then WhatsApp, Telegram and social accounts, each tested with a real message.
Restore into a copy that cannot reply
PostgreSQL, the bucket and the environment file with its keys go offsite daily, encrypted. Once a month we restore all three into a scratch environment and open a conversation there. Outbound traffic from that copy is closed, so it cannot poll a mailbox or answer a customer.
Keep up with monthly releases
Chatwoot ships roughly once a month, with hotfix releases in between, and most releases migrate the database. The Pilae Agent runs each release on a copy first. Once you approve, it goes out in your window, with the previous image and a pre-upgrade snapshot ready.

What Chatwoot is, and who runs it

Self-hosted Chatwoot for live chat and a shared inbox

Chatwoot is a shared inbox for teams that answer customers on more than one channel. Website chat, email, WhatsApp, Messenger, Instagram, Telegram, Line, SMS and TikTok arrive in one list, and agents handle them with canned replies, macros, private notes and labels. Automation rules and teams decide who picks up what, and reports and satisfaction surveys show how it went. A help centre publishes articles so customers can answer common questions themselves. It covers what most teams use the Intercom inbox and Messenger for. Teams whose support runs on tickets rather than chats are often better served by Zammad.

It runs on machines dedicated to it, on your premises or in one of the six Swiss and EU Pilae Cloud regions, with six more outside them. Conversations, contact records and attachments stay in the database and bucket you chose. Running your own instance does not change the channels, though: a WhatsApp message passes through Meta and a Telegram message through Telegram, whoever hosts the inbox. The website widget is the channel that stays on infrastructure you picked from end to end.

The widget has to load on your public site, so part of Chatwoot faces the internet by design. The gate on port 443 publishes only the paths the widget, the help centre and the channel webhooks need. The dashboard, the agent API and the super admin console answer on your private network and nowhere else. We switch off telemetry. Push notifications to Chatwoot’s official mobile apps go through a relay server Chatwoot runs, so we leave them off unless you decide agents need them.

A restore needs three things: the PostgreSQL database, the attachment bucket and the environment file, which holds the keys that sign cookies and encrypt two-factor secrets. We back up all three daily, encrypted, to an offsite location in your chosen country, and restore them into a scratch environment every month. Probes check the web server and the worker every 60 seconds and alert an engineer, because a stalled worker leaves the dashboard up while email stops arriving and replies stop going out. The Pilae Agent takes each monthly release through a copy first, then into your window once you approve it.

Chatwoot licence, paid plans and SAML sign-on

SAML sign-on is the only way to put Chatwoot behind Keycloak or Entra ID, so we raise the Enterprise Edition plan in the first session. Captain accepts any OpenAI-compatible endpoint, so it can use a model you serve with vLLM rather than OpenAI. Pricing for our operation is on request. Talk to us about the channels you answer customers on.

Chatwoot is MIT-licensed except for its enterprise directory, which is under the Chatwoot Enterprise License: free for development and testing, and in production only with a paid Chatwoot plan for the right number of agent seats. The default image carries that directory. The -ce images leave it out, so the Chatwoot code in them is all MIT. They are what we deploy unless you need a paid feature. Captain AI, voice calls, custom branding, agent capacity and custom roles come with the Premium Support plan; SAML single sign-on and SLA policies only with the Enterprise Edition plan. Both are priced per agent per month and activated against a licence server Chatwoot runs, and the subscription is held in your name. Moving from the -ce image to the enterprise one later keeps your data and settings.

Chatwoot system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory: 4 vCPU · 4 GBUpstream's recommended minimum, sized for up to 10,000 conversations a day, plus 1 GB of swap so an upgrade does not run out of memory. On a busy instance the Sidekiq worker alone can pass 1 GB.
Database: PostgreSQL + pgvectorThe only database Chatwoot supports. Current releases need the pgvector extension, so a PostgreSQL without it cannot take the upgrade.
Queue and cache: Redis 7+Holds the background job queue and cached settings. Upstream suggests starting at 100 MB, and it is not on their list of what a restore needs.
Object storage: S3-compatible bucketFor attachments, instead of the default local folder. Visitors who open an attachment in the widget are redirected to a signed URL on the bucket, so that address has to be reachable from outside as well.
DNS and TLS: 1 public hostnameThe widget, the help centre and channel webhooks need an address the internet can reach. Only their paths are published on it.

Migrating from Intercom to Chatwoot

Chatwoot has its own Intercom importer. It is switched off by default on a self-hosted instance, and we turn it on for the migration. Given an Intercom access token that can read contacts and conversations, it copies both and files the history as resolved conversations in separate import inboxes, so it is there for context and never mixed into live work. Attachments do not come across; each affected message carries a note saying how many were skipped. Teammates, teams, routing rules, automations and Messenger settings are not recreated, and the importer leaves help-centre articles out, so we copy those from Intercom's API to Chatwoot's. The live side takes longer: the widget swapped on every site and app, each WhatsApp number and social account reconnected, and the routing rebuilt by hand. Fin, Intercom's AI agent, has no equivalent in the free edition.

List every channel
Each site and app that loads the Intercom Messenger, each WhatsApp number, social account and support address, with the team that answers it. This list is the cutover plan.
Import contacts and history
Chatwoot's importer reads Intercom through a token made for the migration. We compare the imported counts with Intercom's, read the error and skip logs, then revoke the token.
Rebuild routing and replies
Teams, inbox assignment, automation rules, macros and canned responses are set up in Chatwoot, and help-centre articles are copied across with their categories.
Swap the widget, then the numbers
The Chatwoot widget replaces the Intercom code in one release. WhatsApp numbers and social accounts move one at a time, each tested with a real message before the next.

What the gate publishes, and what stays private


/widget, /packs, /vite/assets, /brand-assets, /audio/widget	Visitors loading the chat bubble	Published
/api/v1/widget/*, /cable	The widget sending and receiving messages	Published, rate-limited by Chatwoot
/rails/active_storage/*	Visitors opening an attachment	Published, redirects to a signed bucket URL
/hc/, /survey/responses/, /public/api/v1/csat_survey/*	Help-centre readers, satisfaction surveys	Published
/webhooks/whatsapp/, /webhooks/telegram/	Meta's and Telegram's servers	Published; the message has already passed through them
/app, /api/v1/accounts/, /auth/	Agents and your own integrations	Private network only
/super_admin, /monitoring/sidekiq	Operators	Private network only

An example for acme's instance. The gate publishes the paths that visitors, help-centre readers and the messaging platforms have to reach, and nothing else. The dashboard, the agent API and the super admin console answer only on the private network, so a password taken from an agent is no use from outside.

What Pilae is responsible for

A pinned version

A version we have run, not whatever latest resolves to that day.

A runbook

What it depends on, how it fails, what to do about it. In your repository.

A restore drill

Backups restored on a schedule. A backup nobody has restored is a file.

A patch window

Security updates in a window you agreed, with a rollback ready.

Someone watching

Every endpoint probed on the minute. An alert reaches a person, not a dashboard nobody opens.

Where it runs: zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware
Who holds the credentials: You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.
If you leave: The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What drives the price of running Chatwoot

Pricing is on request: a fixed price for onboarding, then a monthly price for Chatwoot, quoted in writing within five business days. The plans set what every deployment includes; these are the inputs the quote is built from.

Instance size: The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.
High availability: One machine with tested restores, or a replicated setup that keeps serving when a node fails.
Storage and backups: How much data it holds, how long backups are kept, and point-in-time recovery for its database.
Plan and support: Essential, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.
Region: Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where it is passed through at cost plus a fixed margin.
Sign-on and integrations: Single sign-on, directory sync, mail relays and the other systems the app has to reach.

Chatwoot: common questions

Is Chatwoot open source?

Mostly. Everything outside its enterprise directory is MIT, and the -ce images leave that directory out, so the Chatwoot code we deploy by default is all MIT. The enterprise directory is source-available under the Chatwoot Enterprise License and needs a paid plan per agent seat in production. The Captain assistant, custom roles, audit logs, SLA policies and SAML sign-on live there.

Where do our conversations and attachments live?

In PostgreSQL and a bucket, on dedicated machines in the Pilae region you chose or on your own hardware. That is Chatwoot's copy. A message that arrives over WhatsApp, Messenger or Instagram has passed through Meta, and a Telegram message through Telegram, wherever Chatwoot runs.

Can agents sign in through Keycloak or Entra ID?

Only over SAML, which is in the Enterprise Edition plan. Chatwoot has no OpenID Connect or LDAP sign-in, and the free edition offers passwords with two-factor codes, or Google sign-in. Without the plan, agents sign in with a password and a two-factor code, the dashboard stays on the private network, and a leaver has to be removed in Chatwoot as well as in your directory.

Chatwoot or Zammad?

Chatwoot for live conversations on chat and messaging apps, answered by whoever on the team is online. Zammad for tickets: teams whose work is mostly email queues and cases that run for weeks usually find it the better fit. In Chatwoot, SLA policies need the Enterprise Edition plan.

Can Captain run on our own model?

Yes. Captain, the assistant that replies to customers on its own, takes an OpenAI key or any OpenAI-compatible endpoint, so it can point at a model you run instead of OpenAI. It needs a paid plan. AI Assist in the reply box, for rewrites, summaries and suggested replies, is in the MIT build and uses the same endpoint setting without a plan. We test whether a local model answers well enough in your languages, on your own help-centre articles, before it is switched on for customers.

Back to apps

Bring us your Chatwoot. We will tell you what it takes.

Thirty minutes on the deployment you already have, or the one you are about to start.

Start with one workload Book a 30-minute briefing