Open-source customer support software: the complete guide

Open-source customer support software lets you run your help desk, live chat, knowledge base, status page and feedback board on your own terms: on your servers, in your region, with code you can read and keep. It also hands you the servers, backups and upgrades.

This guide is for support leads, founders and engineers weighing that trade. It explains the licences, maps the main projects by module with their licence and activity, and is honest about the work. We make Quackback, an open-source support suite, and we say where other projects are the better choice. If you're after a help desk specifically, our open-source help desk page compares the ticketing tools in detail.

Why choose open source for customer support

Support software holds some of the most sensitive data a company has: names, email addresses, order details, screenshots and the things customers say when they're frustrated. Open source changes who controls that data and what happens if the vendor changes course.

• Data ownership. Self-hosted, every conversation lives in a database you run. No vendor can read it, train on it or lock you out of it.
• Residency. You choose the country, the cloud account and the network. That matters for public sector, health, finance and anyone whose customers ask where their data lives.
• A real exit. If prices rise or the product goes somewhere you don't want, you keep running the code you have. Your data is already in a format you control.
• Auditability. Your security team can read exactly how data is stored, what leaves the server and which AI provider sees what.
• Fit. You can change the code, build on the API or send a fix upstream instead of waiting on a roadmap.

The trade is responsibility. When you run it, you own uptime, backups, upgrades and security. Later sections cover what that takes and when a hosted version of the same open-source code is the better deal.

Open-source licences explained

"Open source" has a precise meaning: a licence approved against the Open Source Definition, which lets anyone use the software for any purpose, read and change the code, and share it. Within that, licences differ on what you owe back. Outside it sit licences that publish code but restrict use.

Two patterns sit on top of the licence. Open core publishes most of the code under an open licence and keeps some features in a directory with a commercial licence: Chatwoot, Docmost and LogChimp work this way. Paid modules keep the core free and sell add-ons, as FreeScout does. Neither is wrong, but check that the features you need, often SSO, SLAs, reporting and AI, are on the open side.

A contributor licence agreement (CLA) is the other thing to read. It lets the company that owns the project relicense contributions, which is how dual licensing works. It also means the company could change the licence of future versions; the releases already published keep theirs.

The open-source support landscape by module

Customer support breaks into five jobs: a help desk for tickets and email, live chat on your site, a knowledge base customers search, a status page for incidents, and a place to collect feature requests. Most open-source projects do one or two of them well. Filter by the module you need, or by the licence you can accept.

Where each one wins, honestly:

• Ticketing depth: Zammad. Years of work on routing, SLAs, triggers, reporting and phone integrations. If your team lives in tickets and phone calls, start there.
• Live chat reach: Chatwoot. The most popular open-source live chat, with many messaging channels. Its AI and some team features are in the enterprise directory.
• A light shared inbox: FreeScout. Cheap to run on ordinary PHP hosting, with paid modules for what you need.
• Internal knowledge: BookStack, Wiki.js, Docmost. Mature editors for team docs. A public help center wired to your inbox and AI takes more work.
• Status pages: Uptime Kuma, Gatus, Upptime. Monitoring first, with a status page on top. Upptime needs no server at all.
• Feedback: Fider. A focused voting board that's been running for years.

Quackback is the one project in the table that covers all five modules in one app, under AGPL-3.0 with no enterprise edition. It's also far younger and smaller than Zammad or Chatwoot, and its channels today are live chat, email and GitHub issues. If you need phone, WhatsApp or social channels, look at those two first.

One suite or a stack of single tools

You can assemble open-source support from single-purpose projects: a ticketing system, a chat tool, a wiki, a status page and a feedback board. Each may be the best at its job. The cost is everything between them.

A stack makes sense when one module matters far more than the rest, or when you already run some of the pieces. A suite makes sense for a small team that would rather upgrade one thing.

What self-hosting really takes

The download is free. Running it well is a recurring job with a named owner. Before you choose, decide who does each of these.

Email is where most self-hosted support quietly fails. A help desk sends replies, notifications and sign-in links, and receives customer mail. Send through a dedicated provider, not the server itself. Publish SPF and DKIM records and a DMARC policy; Gmail requires them for bulk senders and treats unauthenticated mail with suspicion. Then watch bounces: a reply that lands in spam is worse than no reply, because nobody knows it happened.

Backups only count once you've restored one. Keep database dumps and uploaded files off the server, and practise a restore to a fresh machine. Many upgrades include database migrations that can't be reversed, so the backup is your rollback.

Updates compound. Skipping a few releases turns a five-minute upgrade into an afternoon of reading migration notes. Pin versions, upgrade on a schedule, and subscribe to the project's security advisories.

Scaling is rarely the first problem. A small team's support fits comfortably on one modest server. Disk filling up with attachments and logs is far more common than running out of CPU.

How to deploy Quackback

Quackback ships as one Docker image for x86 and ARM servers. It needs PostgreSQL 14 or newer with the pgvector and pg_trgm extensions, and S3-compatible storage for uploads. There's no Redis or separate queue to run: background jobs use the database.

• Docker Compose. The production Compose file starts the app with PostgreSQL and object storage on one host. Copy the example environment file, fill in your secrets and domain, and start it. Deploy with Docker.
• Docker with your own database. Run the image against a managed PostgreSQL and bucket you already have.
• Railway. A one-click template sets up the app, PostgreSQL with pgvector and a storage bucket. Add a custom domain and an email provider afterwards. Deploy on Railway.
• Without Docker. Build from source with Bun on any server. Manual install.

For outbound email, configure exactly one provider: SMTP, Amazon SES or Resend. Inbound mail can come in over IMAP. To grow, split the app into web processes, which scale sideways, and worker processes for background jobs, all sharing the same database and storage, and run migrations as a separate step before rolling out. Scaling guide.

Pin a release tag rather than latest, back up before every upgrade, and read the release notes: migrations run on startup and aren't reversible. The source is on GitHub.

Open-source AI agents and bringing your own key

AI support agents raise the stakes on data control. Every question a customer asks, and every help center article retrieved to answer it, goes to a model provider. With open source you can see exactly what is sent and choose where it goes.

Bring your own key (BYOK) means the software calls a model provider with your account and key, and you pay that provider directly. The best implementations accept any OpenAI-compatible endpoint, which covers the large providers, AI gateways, routers and model servers you run yourself. That last option keeps conversations inside your own network.

Check two things when you compare projects. First, whether the AI features are in the open-source code at all: in open-core projects they're often in the enterprise directory. Second, whether the agent can act, not only answer, and how you limit what it may do.

In self-hosted Quackback, AI features are off until you set a key and base URL for an OpenAI-compatible endpoint and choose the models. Then the agent answers in the widget from your help center, changelog and status, with each action set to Allow, Ask or Never, and Copilot drafts replies for your team. BYOK is for self-hosted installs. On Quackback Cloud, AI is included and there's no key to manage.

Security when you run it yourself

Open source lets anyone inspect the code, which helps, but it doesn't make your install secure. On your servers, security is your job.

• Put the app behind TLS and a reverse proxy, and keep the database and storage off the public internet.
• Generate long random secrets, keep them out of version control, and rotate them when people leave.
• Patch the operating system and the app on a schedule, and watch the project's security advisories.
• Use single sign-on where you can, and give each teammate the narrowest role that works.
• Know what leaves the server: email, AI calls, telemetry and integrations.

For Quackback specifically: integration credentials are stored encrypted in the database, anonymous daily usage statistics can be switched off with one environment variable, and AI tools you set to Never are left out of the model's turn entirely. Report vulnerabilities to security@quackback.io or through a private GitHub advisory. Quackback is provided under AGPL-3.0 without warranty, and compliance work on your own servers depends on how you run them.

When Cloud is the better choice

Many teams choose open source for the exit, not because they want to run servers. For them, a hosted Cloud built on the same open-source code gives the guarantee without the pager.

Cloud is usually the better choice when:

• Nobody on the team can own upgrades, backups and email.
• Your residency requirement is "in the EU", not "on our own hardware".
• You want AI without choosing models or managing a provider account.
• Support is critical and you'd rather someone else is on call.

Quackback Cloud runs the same codebase as the open-source release. It's hosted in the EU, in the Netherlands, and email goes out through Amazon SES in Ireland. It's updated, backed up and monitored for you, Quackback AI is included, and because the code is the same, the option to self-host stays open. Every signup starts with a 14-day Pro trial.

Continuity and forking

The quiet promise of open source is what happens on a bad day: the company is acquired, pivots, raises prices or shuts down. With a true open-source licence, the code you run stays usable. You can keep running your version, hire someone to maintain it, or join a community fork.

Three questions tell you how real that promise is:

1. Is everything you use in the open code? A fork of an open-core project loses the enterprise features. Make sure what you depend on is on the open side.
2. Is there a CLA, and what does it allow? A CLA lets the owner change the licence of future versions. Published releases keep their licence, so you can always fork from the last open one.
3. Is the project alive? Recent releases, issues that get answers and more than one maintainer. Archived projects, such as Astuto, and projects in maintenance mode, such as Papercups, still run, but nobody is fixing them.

Quackback is AGPL-3.0, and every feature ships in the AGPL codebase; there's no closed enterprise edition. Contributors sign a CLA that lets Quackback Ltd also offer commercial licences. AGPL also protects a fork: nobody, including us, can take a modified version closed and offer it as a hosted service without sharing the changes.

Support for open-source projects

Open-source maintainers have their own support problem: questions, bug reports and feature requests arrive as GitHub issues, in discussions, in chat and by email, and the issue tracker fills with things that aren't bugs.

• Give questions a home outside the issue tracker: a searchable help center or discussions board.
• Move feature requests to a public voting board, so popular ideas rise and duplicates get merged.
• Publish a changelog that tells the people who asked when their request ships.
• Add a SUPPORT.md that tells people where each kind of question goes.

Quackback can take GitHub issues as a channel alongside live chat and email, so issue reports land in the same inbox as everything else, and requests can become votes on a public board by hand.

How to decide: a decision tree

Start with where the data must live and who will run it. Pick the product after that.

Then shortlist by module:

• Heavy ticketing, phone and many channels: Zammad, then Chatwoot for chat.
• A cheap shared inbox on PHP hosting: FreeScout.
• Support, help center, status and feedback in one app: Quackback.
• One module only: the specialist for that module in the table above.

Whatever you choose, run a two-week trial with real conversations, do one upgrade and one restore before launch, and write down who owns the server.