Open source ticketing system: what you gain, what you give up, and what to check
An open source ticketing system is usually evaluated as "the free version of the paid thing." That framing is wrong in both directions, and it leads people to the wrong choice about equally often.
Open source help desks are not stripped-down commercial products. They are built by different people for different reasons, and the capability gaps run in both directions — there are things the free self-hosted desks do better than the subscription products, and things they consistently do not do at all.
We have counted those gaps. This page is what the evidence shows, what it costs to run one, and how to tell which situation you are in.
Three categories that get lumped together
Searches for an open source ticketing system return three different kinds of product, and mixing them up is the most common expensive mistake in this category.
Mature open-source help desks. Real projects with real communities, self-hosted, genuinely free. These are the ones worth evaluating seriously.
Commercial products with a free tier. Not open source at all — hosted, capped, and you cannot see or modify the code. Often perfectly good, but do not confuse "free" with "yours".
Marketplace scripts. One-off purchases from code marketplaces, typically inexpensive, sold as a complete help desk. Source code is included, which is why they surface in open-source searches, but the resemblance ends there.
That third category deserves a warning, because our counting found the gap is not subtle. Across 18 real help desks, a REST API appeared in all 14 of the SaaS and open-source products — and zero of the 4 marketplace scripts. Service-level agreement tracking with breach views showed the same pattern: present in all six SaaS products and seven of eight open-source ones, and none of the four scripts.
If a cheap script is your candidate, assume you will never integrate it with anything and never report on response times. For some teams that is fine. It should be a decision rather than a discovery.
Where open source actually wins
This is the part that gets missed, because it is counterintuitive if you assume free means lesser.
Collision detection. When two agents open the same ticket, a good desk warns them before they both reply. It appeared in 10 of 18 products overall — and the split is the interesting part: it is standard in the major open-source desks, and plan-locked behind higher tiers in the leading commercial products. A small support team on a self-hosted desk gets a capability that a paying customer on an entry plan does not.
No per-agent pricing. Commercial help desks charge per agent per month, which quietly shapes behaviour: teams share logins to avoid seats, and shared logins destroy the audit trail and make collision detection meaningless. Self-hosted removes that pressure entirely — everyone gets an account because accounts are free.
Your data stays yours. Support tickets contain customer complaints, personal data, and sometimes security reports. Self-hosting means that content is not on somebody else's infrastructure under somebody else's retention policy.
It cannot be discontinued. The product will not be acquired and sunset, repriced, or have the feature you depend on moved to an enterprise tier.
Where open source consistently loses
The gaps are as predictable as the wins.
Knowledge-base deflection. Showing likely-relevant articles while the customer is typing their ticket, so they solve it themselves and never submit. This is the cheapest possible way to reduce ticket volume, and the counted split is stark: present in all six SaaS products and three of four marketplace scripts, but one of eight open-source desks. If deflection matters to you, assume you are building it.
Live chat. Inverted from what you would expect. All four marketplace scripts ship live chat, and five of eight open-source desks lack it entirely. Chat is a visible selling feature, so cheap commercial products lead with it while open-source projects prioritise the ticket workbench.
Setup and polish. Installation, upgrades, mail routing, spam handling, and inbound email deliverability. Getting a self-hosted ticketing system to reliably receive email is more work than anyone expects, and email is how tickets actually arrive.
Somebody to call at 9am. Community forums are not an incident response plan.
Three shapes of open source desk, and which team each suits
The mature projects are not variations on one design. They come in three shapes, and picking the wrong shape causes more pain than picking the wrong project.
Mail-centric desks. Built around a shared mailbox done properly — conversations, assignment, notes, canned replies. Light, quick to run, and they feel familiar to a team coming from Outlook or Gmail. Best for customer-facing support where most contact arrives as email and the work is answering people.
Weak on: asset tracking, approval chains, anything resembling formal IT process.
ITSM-shaped desks. Built around an internal IT function — an open source IT ticketing system in the proper sense, with incidents, requests, change management, and often an asset register. Heavier to run and configure, and considerably more capable if that is your job.
Best for internal IT, where you need to know which laptop belongs to whom and who approved the software install. Overkill for a five-person team answering customer questions.
Workbench desks. The middle ground: strong ticket handling, custom fields, automation rules and an API, without the full service-management apparatus. Usually the right default for a product company handling customer support at moderate volume.
The practical test: write down where your tickets come from and who they are about. Tickets from customers about your product point at mail-centric or workbench. Tickets from colleagues about their equipment point at ITSM. Teams that pick by feature list instead of by that sentence generally end up running an asset database they never populate.
What running a self-hosted ticketing system costs
The licence is free. Nothing else is.
Inbound email is the real operational burden. A support desk lives or dies on email arriving reliably. That means correct DNS records, spam filtering that does not eat customer replies, threading that keeps a conversation as one ticket rather than fourteen, and outbound deliverability so your replies do not land in junk. This is the single most common reason self-hosted help desk deployments quietly fail.
Upgrades on a system holding personal data. Support tickets are full of customer information, so security releases are not optional and falling behind is not an acceptable state.
Backups you have tested restoring. Untested backups are a belief, not a capability.
One accountable person. Not a team that could do it — one person whose role includes it. This is the best single predictor of whether self-hosting works, in every category, and help desks are no exception.
What any ticketing system has to get right
From the same counted set of 18 real help desks, ranked by how often each capability appears:
| Capability | Found in |
|---|---|
| Ticket lifecycle and statuses | 18 of 18 (100%) |
| Auto-assignment and routing | 17 of 18 (94%) |
| Custom fields | 17 of 18 (94%) |
| Automation — trigger, condition, action | 16 of 18 (89%) |
| REST API | 14 of 18 (78%) |
| SLA tracking with breach views | 13 of 18 (72%) |
| Live chat | 13 of 18 (72%) |
| Collision detection | 10 of 18 (56%) |
| Knowledge-base deflection on the portal form | 10 of 18 (56%) |
The top four are effectively universal — every serious product has them, so they differentiate nothing and should not be what a vendor sells you on.
Custom fields at 94% is the one people underestimate. It looks like a nice-to-have and it is structural: it is how a generic ticket becomes your ticket, carrying the order number, the asset tag, the environment, the account tier. A desk without them forces that information into free text, where it cannot be filtered, routed or reported on.
Automation at 89% is where the hours are. Not the workflow diagrams in the marketing — the unglamorous rules that route by keyword, escalate on age, and close stale tickets. A desk without a real trigger-condition-action engine means a person doing that sorting by hand, forever.
Getting one adopted, which is harder than installing it
Most self-hosted help desk projects that fail do not fail technically. They fail because the team keeps using the mailbox.
Route the mailbox into the desk, do not ask people to change where they look. If support@ still delivers to a shared inbox as well as the desk, half the team will answer from the inbox and the desk's data is fiction within a fortnight. Point the address at the desk and let the desk be the only way to reply.
Import the last few months of history. A desk with no past is one where every "have we spoken to this customer before" question sends someone back to the old mailbox — which teaches people the desk is incomplete.
Set up the automation rules before launch, not after. The first week sets the habit. If tickets land unrouted and someone sorts them manually, that becomes the process and nobody revisits it.
Give everyone their own login on day one. This is the free-to-self-host advantage and the main reason to use it — no per-seat pressure means no shared accounts, which means assignment, collision detection and audit history all actually work.
Decide what "closed" means and write it down. The single most common source of distrust in a new desk is two people using the same status to mean different things.
When self-hosting is the wrong answer
- Nobody owns it. It will run beautifully for six months and then stop being patched.
- You need deflection or chat now. Both are open-source weak points. Buy, or plan to build.
- Your team is two people. Free tiers of commercial products are generous at that size, and the operational burden is the same whether you have two agents or twenty.
- Email is already painful. If your mail setup is fragile, self-hosting a mail-driven application will not improve it.
The third option
If the open-source desks do not fit and the subscriptions do not either, building one is now a realistic third answer — a coding agent can produce a working ticket workbench in a couple of days.
The case for it here is specific and worth stating plainly: help desks are unusually workflow-shaped. Every organisation routes, escalates and closes differently, and most of the pain in adopting any desk is bending your process to its assumptions. That is precisely the situation where owning the software pays, and it is why help desk is one of the stronger custom-build cases in business software.
The order to build in follows the counts above. The ticket lifecycle first, because it is the product. Then routing, then custom fields — early, because retrofitting them means migrating every existing ticket. Then the automation engine, then an API, because everything else you own will eventually want to create a ticket.
Two things an agent will skip unless told: SLA tracking with breach views, which needs to be in the data model from the start rather than computed in a report, and collision detection, which sounds trivial and is the difference between a shared inbox and a support desk.
If free hosted options are still on your list, free ticketing system covers what those tiers give you and where they stop. And if you are building, the Helpdesk Ticketing planner is the specification we hand our own coding agents — the lifecycle, routing, SLA model and the controls that make a desk replace a subscription rather than imitate one.