Open-source alternatives to Zendesk: 3 customer support helpdesk tools compared

A Rails inbox, a foundation-owned suite, and a PHP shared mailbox

Zendesk is a hosted helpdesk: tickets from email, chat and social channels, agent workflows, a knowledge base and reporting. People look elsewhere for three reasons. Pricing is per agent. Customer conversations and contact data live on the vendor's servers. And chat and AI are add-ons priced separately from the core.

The three projects here are built for different-sized operations, and the technology each one chose shapes who can run it.

chatwoot/chatwoot is the most feature-forward of the three. The README describes an omnichannel desk supporting live chat on your website, email, Facebook, Instagram, Twitter, WhatsApp, Telegram, Line and SMS, all in one inbox, plus a help center portal for publishing articles and FAQs. Around that it lists private notes and mentions, labels, canned responses, auto-assignment, custom views and filters, business hours and auto-responders, teams and automation, agent capacity management, contact segments, campaigns, custom attributes and pre-chat forms. It also has an AI agent called Captain, a Crowdin-based translation process, and a Live View of ongoing conversations alongside conversation, agent, inbox, label, team and CSAT reports.

zammad/zammad is the most institutional. The README is careful about ownership: the software is and will stay open source under the GNU AGPLv3, the source is on GitHub, and it is owned by the Zammad Foundation, which it describes as independent of commercial providers such as Zammad GmbH, while the development itself is carried out at Zammad GmbH in collaboration with the community. The feature surface is the multi-channel one: email, chat, telephone and social media from a single interface. Distribution is unusually thorough for an open source helpdesk, with Docker images, a Helm chart on Artifact Hub, and DEB and RPM packages built from stable and develop branches.

freescout-help-desk/freescout is the lightest. The README describes it as a pure PHP and MySQL application built on Laravel, with unlimited support agents, tickets and mailboxes, omnichannel intake across email, WhatsApp, Telegram, Facebook, Slack and live chat, a web installer and updater, OAuth for Microsoft Office 365 and Google Workspace, phone conversations, collision detection when two agents open the same conversation, open tracking, internal notes, forwarding, merging and moving, and a powerful search. It states there are no minimum CPU or RAM requirements and that it can be deployed on shared hosting.

Left out, and worth saying why: the field service and workforce management suites that happen to include a ticketing module, and the in-app messaging widgets that are messaging products rather than helpdesks. Both exist; neither is what a team leaving a hosted support desk for data residency is looking for.

Why Intercom, Freshdesk and Help Scout are not on this list

Intercom, Freshdesk and Help Scout are the three names that come up next to Zendesk in most of these searches, and none of them is here, because all three are hosted services that keep the conversation history and the contact records on the vendor's infrastructure.

None of the three deserves a dismissal on quality. Intercom is unusually good at the messenger-plus-helpdesk combination for product-led teams. Freshdesk is a full helpdesk with a free entry point. Help Scout has a long history as a deliberately small, email-first desk. If your support operation is small, if nobody is going to export the ticket history, and if nobody needs to prove where a customer's email is stored, a hosted service remains a perfectly reasonable answer and everything on this page will add operational work.

The reason they do not qualify is the second and third reasons on the list. Per-agent pricing is a real constraint when the agent count includes everyone who occasionally answers a ticket, and separately priced chat and AI add-ons make the total cost of a channel hard to predict. Both of those are symptoms of the same underlying fact: the data is not yours to move.

Once customer conversations are subject to a data residency requirement, a contractual commitment about processing, or a plain policy decision about where personal data lives, the choice stops being about features. It becomes which server you are willing to run.

Also absent, and worth naming: hosted helpdesks built on these open source projects. A vendor who will run Zammad or Chatwoot for you is a real option, and the Zammad README points at a cloud service for exactly that audience. It keeps the software and gives up the part that prompted the search.

Choosing by scenario: a two-person support team, a growing team, a company with residency rules, a developer extending the desk

Support volume, not features, is usually what decides this, because the three differ most in how much they want you to operate.

A two-person team handling email and a live chat widget should look at freescout-help-desk/freescout. The README describes a system with no minimum CPU or RAM requirement that can be deployed on shared hosting, installed through a web installer, and updated through the web as well. Unlimited agents and mailboxes means the per-agent pricing problem disappears. The constraint is that the whole thing is PHP, so somebody has to be comfortable with that.

A growing team with several channels in play should look at chatwoot/chatwoot. WhatsApp, Telegram, Line, Instagram and Slack alongside email and live chat is a channel list a modern support team is often asked to cover, and the help center portal lets some of the volume never reach an agent. The cost is the runtime: a Rails application with PostgreSQL, Redis and Sidekiq is a normal thing to run and a real thing to own.

A company with data residency or contractual requirements usually ends up choosing between Chatwoot and Zammad on operational appetite rather than on features. Both keep conversations and contacts in your own database. Zammad is the more thorough product and the heavier install, with three data stores including Elasticsearch; Chatwoot is the more modern channel story and the more familiar Rails stack.

A developer extending the desk should note that both Zammad and FreeScout document a REST API, which is what a custom integration or a dashboard app needs. The Zammad README also links a developer manual, and Chatwoot describes dashboard apps for embedding internal tools inside the inbox. This is the scenario where the choice is made on API shape, and it is worth prototyping before committing.

What each one asks you to run: Postgres and Redis, Elasticsearch too, or just PHP and MySQL

The install commands on this page make the operational difference concrete, including where one of them is not a deployment.

chatwoot/chatwoot shows docker compose up -d. The README points at a Heroku one-click deploy, a DigitalOcean one-click Kubernetes app, Docker images on Docker Hub and a Helm chart on Artifact Hub, and a deployment page for everything else. Underneath is the part that matters: our analysis of Chatwoot describes it as a Rails application you run with PostgreSQL, Redis and Sidekiq, and notes that its own install is documented and repeatable while the operational cost is left to you. That is a fair summary. A background job system is the piece that needs monitoring, because a queue that stops is a support desk that quietly stops answering.

zammad/zammad has no install command in our analysis, and the reason is the distribution model. The README points at a Docker image on Docker Hub, a Helm chart on Artifact Hub, and binary DEB and RPM packages for stable and develop, which means you choose how the software arrives rather than running one script. The repository also carries no tagged GitHub releases, so the version you run is the one in the image or the package. Our analysis adds the operational detail that the README does not lead with: PostgreSQL, Redis, and Elasticsearch for full-text search.

freescout-help-desk/freescout also has no install command in our analysis, and the README points instead at a long list of one-click routes: a Docker image, Pikapods and Zenith for managed open source app hosting, Hostinger, Softaculous and Fantastico for control panel installs, Cloudron, and a bash script for Ubuntu. The requirements it states are Nginx, Apache or IIS, PHP 7.4 to 8.x, and MySQL, MariaDB or PostgreSQL. There is no Elasticsearch and no job queue, which is why our analysis calls the Docker image the fastest way to check the requirements against a real installation.

The pattern is worth stating plainly. A helpdesk is a database plus a mail poller plus something that answers an inbound webhook. The first two are universal. The third is what separates a Rails app with a queue from a PHP application on shared hosting.

Licences: two AGPL-3.0, and one repository whose metadata disagrees with its README

Two of these are straightforwardly AGPL-3.0, and the third needs a sentence of care before it needs a lawyer.

zammad/zammad is AGPL-3.0, and the README says the software is and will stay open source under it. The AGPL clause that matters for a helpdesk is the network one, and our analysis of Zammad puts it plainly: the licence requires releasing modifications if you distribute the software, which matters for teams building proprietary extensions on top of it. Internal hosting without modification is the ordinary case and is unremarkable.

freescout-help-desk/freescout is also AGPL-3.0. Same reasoning, same shape of decision. Our analysis of FreeScout frames it as a condition you have to live with for any code you modify, and it pairs that with the operational point that there is no vendor SLA behind the software.

chatwoot/chatwoot is the interesting one, because the sources in the repository do not agree. The repository metadata reports a custom licence that GitHub cannot classify, and the README footer describes Chatwoot Inc as releasing it under the MIT License. Two signals pointing in different directions in the same project is a reason to open the LICENSE file before you build a compliance process around it, not a reason to assume the friendlier one. Our analysis of Chatwoot does not raise this, which is precisely why it is worth checking yourself.

One point applies to all three. A helpdesk holds the most sensitive data most companies have outside the HR system: what a customer complained about, what they were charged, and what was said in a conversation with an agent. The licence on the software does not change that, and none of these three makes anybody else's job of protecting it.

Bottom line

Pick freescout-help-desk/freescout for a small team that wants a shared mailbox and unlimited agents on plain PHP and MySQL, chatwoot/chatwoot for a growing team that needs WhatsApp, Telegram, social channels and a help center portal, and zammad/zammad when you want a foundation-owned product with the most complete distribution options and can run PostgreSQL, Redis and Elasticsearch. Before committing, confirm the Chatwoot branch or tag guidance still matches the version you plan to deploy, check that the FreeScout modules you need exist in the official or community listings, and read the Chatwoot LICENSE file rather than relying on either of the two signals in the repository.

Sources

1. Zendesk official site
2. chatwoot/chatwoot repository
3. chatwoot/chatwoot README
4. zammad/zammad repository
5. zammad/zammad README
6. freescout-help-desk/freescout repository
7. freescout-help-desk/freescout README