Open source ticketing system: 5 self-hosted options compared

The open source ticketing systems worth a trial are osTicket, FreeScout, Zammad, GLPI and Request Tracker (RT). For customer support arriving by email, start with osTicket or FreeScout. Choose Zammad when you want several channels in one desk and have someone to run its services. For an open source IT ticketing system, where tickets connect to laptops, software and approvals, start with GLPI or Request Tracker. All five are actively maintained, self-hostable and published under GPL or AGPL licences.

Open source ticketing systems compared

Checked on 18 October 2026. Licences and release versions come from each project's GitHub repository (osTicket, FreeScout, Zammad, GLPI, RT); the stack column comes from the official requirements pages linked below. "Self-hosting effort" is our reading of how many services you must install, patch and back up. It is not a measured benchmark, and we have not run a comparative installation of these five.

What each one includes, and what costs extra

None of the vendors publish prices for every paid option on the pages we checked, so this table lists what exists rather than what it costs. Get a quote for the modules or hosting you need before you compare against a subscription desk.

osTicket: the conventional support queue

osTicket is the safest default when customers email in and agents work a queue. Its feature page covers help topics with their own forms, custom queues, SLA plans that escalate overdue tickets, and ticket locking so two agents do not reply at once. The installation guide asks for PHP 8.2 to 8.4 (8.4 recommended), MySQL 5.5 or later and a web server with URL rewriting. Inbound mail is set up separately through email piping or POP3/IMAP fetching, so test that first.

FreeScout: a shared mailbox that behaves like a help desk

FreeScout is the lightest install here. The project says it runs on ordinary PHP/MySQL hosting, including shared hosting, with no limits on agents or mailboxes. The trade-off is in the module catalogue: workflows, the API, SSO, a knowledge base and a customer portal are all paid add-ons. The core is free; a fully featured FreeScout usually is not. List the modules you need before you call it the cheap option.

Zammad: multi-channel support with more to operate

Zammad brings email, chat, phone and social messaging into one ticket view. Its software prerequisites require PostgreSQL 15 or newer, Redis 7 or newer and an Nginx or Apache reverse proxy; Elasticsearch is optional but strongly recommended for search and reporting, and Memcached is needed in container or cluster setups. Packages exist for current Debian, Ubuntu, RHEL and SUSE releases; elsewhere the route is Docker Compose or Kubernetes. Budget for the person who upgrades and restores all of those services together.

GLPI: IT service management with an asset register

GLPI is an open source IT ticketing system in the full sense. Tickets are typed as incidents or requests, with separate modules for problems and changes, and they link to an inventory of computers, software, network equipment, printers and phones. The prerequisites support only MySQL and MariaDB. That page currently documents the 10.0 and 11.0 series, while 12.0.0 shipped on 7 October 2026, so confirm the requirements for the release you install. Trial the asset-to-ticket workflow, not just the ticket screen.

Request Tracker: long-running, email-first and scriptable

Request Tracker (RT), from Best Practical, still ships regular releases. It suits IT, operations and security teams that work from shared email addresses and want ticket rules they can script. It documents SLA deadlines with business hours, asset tracking, approvals and a token-based REST 2 API. The RT 6.0.3 README lists Perl 5.26.3 or later, a FastCGI or mod_perl web server, and MySQL 8.0.31+, MariaDB 10.6+, PostgreSQL 13+ or Oracle; SQLite is for testing only. Installing its Perl module dependencies is the step most likely to take longer than planned.

Options we left out

• Redmine is GPL-licensed and can create issues from email, but it is a project management and issue tracker. Consider it for internal work orders or development tickets, not for a customer support desk.
• UVdesk is open source (OSL-3.0), but its latest tagged release was September 2025. Check activity again before relying on it.
• Peppermint's GitHub repository is archived, so it is not a maintained option.

Run the same ticket through every trial

1. Email a new request with an attachment. Confirm it becomes one ticket and the acknowledgement arrives.
2. Reply by email and in the portal. Both replies must land on the existing conversation.
3. Assign it to another agent. Check what the first agent, customer and an unrelated customer can still see.
4. Add an internal note. Confirm it is absent from the customer's page and email.
5. Miss an SLA deadline in a test policy. Check the alert and escalation rather than a coloured badge alone.
6. Back up and restore the ticket, attachments and mail settings in a separate environment.

Record pass, fail or not tested next to each step. Do not award a pass from a feature list. For a custom workflow, the helpdesk planner and audited builds show the boundaries worth specifying before coding.

Looking for admission passes and seat sales? That is event ticketing, a different category. See free event ticketing software or the event ticketing planner rather than a helpdesk package.

IT helpdesk or customer support: pick the shape first

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 (FreeScout, and osTicket in its simplest setup). Built around a shared mailbox done properly: conversations, assignment, notes, canned replies. Light, quick to run, and familiar to a team coming from Outlook or Gmail. Best for customer-facing support where most contact arrives as email. Weak on asset tracking, approval chains and formal IT process.

ITSM-shaped desks (GLPI, and Request Tracker with assets and approvals). Built around an internal IT function, with incidents, requests, changes 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 (Zammad, and osTicket with custom forms and SLA plans). 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.

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, really free. The five above are in this group.

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 in 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 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.

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. Of the five above, Zammad documents chat as a channel and FreeScout sells it as a paid module.

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 arrive.

Somebody to call at 9am. Community forums are not an incident response plan. Several of these projects sell hosting or support for exactly this reason.

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.

Every extra service is another upgrade. A PHP application and one MySQL database is one thing to patch. Zammad's PostgreSQL, Redis and Elasticsearch, or RT's Perl modules, are several, and they must be upgraded in a compatible order. Count the services in the comparison table before you count features.

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:

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, but 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. On FreeScout, check that this is the paid Workflows module before you assume it is included.

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.

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 work.

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 is specific: help desks are unusually workflow-shaped. Every organisation routes, escalates and closes differently, and most adoption pain is bending your process to a product's assumptions. That is where owning the software pays.

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. If you are still pinning down requirements, IT ticketing system counts what a desk has to do across 18 real help desks. 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.