Open source Intercom alternatives: Chatwoot or managed live chat?

First decide whether open source is a requirement

If you need an open source Intercom alternative because you must inspect the source or operate the software yourself, Chatwoot is a relevant option to evaluate. Chatting is a managed website chat product. It should not be presented as an open source substitute. A vendor offering a simpler subscription does not satisfy a requirement to control the application and its infrastructure.

Some teams use open source as shorthand for escaping a large recurring bill. That is a different decision. Ask whether the requirement is source access, control of hosting, specific customization, or a less demanding support tool. Write the answer down before comparing products. Otherwise a technically attractive installation can create an operating commitment nobody wanted to take on.

Separate Chatwoot Cloud from running Chatwoot yourself

Chatwoot offers a hosted service as well as documented ways to run its software on your own infrastructure. Those are different purchases. The cloud pricing page lists a free Hacker plan for up to two agents, 500 monthly conversations, and 30 day retention. Startups is listed at $19 per agent per month. Those hosted limits are not an infrastructure quote for your own deployment.

When evaluating the cloud service, compare the selected plan, channels, retention, and required features. When evaluating your own installation, estimate the cost of running and maintaining it. Do not place a free software license beside a managed monthly subscription and call the difference a saving. That leaves out the part of the job you have agreed to do yourself.

Put a named person behind the infrastructure

The Chatwoot installation documentation describes deployment options and ongoing maintenance. Before choosing one, assign responsibility for updates, backups, monitoring, and restoring service. A container that starts successfully is evidence of installation. It is not evidence that someone will notice an unavailable inbox during a busy morning or recover the records after a failed upgrade.

Ask for a practical ownership plan. Who receives the alert, who has the credentials, and who can recover the system if the usual administrator is away? If the answer is the same founder who must also reply to customers, account for that tradeoff. Running the software can be a good decision, but it should be an intentional responsibility rather than an invisible cost.

Test a restore before relying on the archive

A backup file existing somewhere does not prove that the support team can recover a conversation. During evaluation, restore representative data into a controlled environment and confirm that an authorized teammate can read a complete sample thread. Include the relevant attachments and customer context. Keep the process documented somewhere that does not disappear with the only person who understands the installation.

Choose retention deliberately. Keeping records forever is not automatically a better customer outcome, and choosing your own host does not automatically establish legal or security compliance. Determine what your business needs, how access is controlled, and when records should be removed. Where a formal compliance requirement applies, obtain the appropriate assessment rather than treating source availability as the assessment itself.

Map the Intercom work before changing tools

An Intercom replacement may involve more than a widget and inbox. Record the automations, outbound messages, help content, integrations, and support processes you use today. Decide which must continue and which can stop. The new system must cover the required outcomes, not merely resemble the old messenger in a browser. A source license does not answer that product question.

Use actual examples from your support work to evaluate the candidate. Try a purchase question, a handoff, an unanswered message outside working hours, and a returning customer. Ask the vendor or implementation owner to show those tasks working. Keep the Intercom alternatives guide available when the original requirement turns out to be narrower than replacing the whole platform.

When managed website chat is the better answer

A small team may conclude that it wants to answer website visitors without operating another application. Chatting suits that requirement with a shared inbox, assignments, saved replies, visitor context, and follow up. Growth costs $20 per month with three members included, then $6 per additional member each month. The subscription buys a managed product rather than access to run its source yourself.

That recommendation does not satisfy a mandatory source access or hosting requirement. Keep Chatwoot in the evaluation when those conditions matter. Choose Chatting when managed website support is sufficient and the team benefits from spending its time on customers. Compare the shared inbox and current plans against the work you need, rather than treating the hosting model as a badge of technical sophistication.

Use a complete cost comparison

For your own deployment, include the hosting, storage, email delivery, backup service, and the time of the person operating it. Price a normal month and a recovery event. For a hosted product, include the selected seats, usage, required feature tier, and any tools you still need alongside it. Mark estimates as estimates and replace them with real quotes before deciding.

Choose Chatwoot when its source access, deployment control, and product capabilities justify the responsibilities you can support. Choose managed chat when the goal is simply dependable website conversations with fewer systems to operate. If you still cannot name why the software must be open source, pause the infrastructure project and test the actual support requirement first. That question can save more work than an enthusiastic installation tutorial.

Sources checked on 25 October 2026

chatwoot.com source 1

developers.chatwoot.com source 2

Try it with your own website

Recommended next steps

FAQ