Self-hosted helpdesk and ticketing: how to pick

The four questions that pick your self-hosted helpdesk

A self-hosted helpdesk is easy to install and hard to choose, because the requirements in this category are unusually specific. Four answers cut the field from about twenty projects down to one or two. Decide them before you open a single feature page.

• Does email have to become tickets, or will people use a web form and a login?
• Is this customer-facing support, or an internal IT service desk where a ticket points at a laptop or a server?
• How many agents will ever log in? Two people is a different product from twenty.
• Does anyone need a service level agreement (SLA) clock, asset records, a public knowledge base, or approval steps?

The sections below follow that order. The product list comes last, because the product is the least interesting decision you make here.

Does mail have to become tickets?

If the answer is yes, email is the main integration in whatever you install, and it has two halves that fail in different ways.

Inbound: what actually creates the ticket

Every option in this post reads mail from a mailbox you already own, over IMAP (internet message access protocol) or POP3 (post office protocol). The helpdesk logs in like an ordinary mail client and polls on a timer. Nothing pushes mail into it, so when the timer stops, tickets stop being created and the customer sees no error at all.

osTicket makes the mechanism visible. You set a fetch frequency for each mail account in the admin panel, but enabling fetching is not enough on its own. The poller lives in api/cron.php, and the documented setup is a crontab entry that runs it, commonly every five minutes. The built-in alternative, auto-cron, only fires while a logged-in agent is using the web interface, so on a quiet weekend nothing is fetched until somebody logs in.

GLPI splits the same job in two. A receiver, which is GLPI's name for a mail collector, holds the mailbox credentials, and the mailgate automatic action decides how often collection runs. When tickets stop appearing, check that automatic action before you touch the mailbox. Zammad fetches over IMAP or POP3 from its channel configuration, and on a self-hosted box it can also be fed by fetchmail or by a sendmail pipe.

Threading is the next trap. A customer's reply has to land on the existing ticket instead of opening a second one. Mail threads on the Message-ID, In-Reply-To and References headers, and helpdesks add a ticket reference to the subject line as a fallback, which is why support mail arrives with something like [#123456] in the subject. Strip that token out of the outgoing template to make the mail look tidier, and every reply comes back as a new ticket.

Auto-replies are the last one. Your desk sends an acknowledgement to every new message. If the address it answers is itself an autoresponder, the two can loop until somebody stops one of them. RFC 3834 defines the Auto-Submitted: auto-replied header so that automatic responders can recognise each other and stay quiet, and well-behaved systems set it. Test with a real mailbox before you point the desk at an alias that forwards to a list.

Outbound: the half that decides whether replies arrive

Inbound problems are visible, because no tickets appear. Outbound problems are invisible: the reply is sent, the agent closes the ticket, and the customer never sees it. Your ticket system sends mail as your domain, so the domain has to authorise it.

The domain needs an SPF (sender policy framework) record that lists whatever sends the mail. It also needs DKIM (domainkeys identified mail) signing, and a DMARC (domain-based message authentication, reporting and conformance) record whose policy agrees with both. Check what is published today before you install anything:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

The first command should print a line beginning v=spf1. The second should print a line beginning v=DMARC1. The third answers only for the selector name your signer uses, so an empty result there usually means you looked up the wrong selector rather than that DKIM is missing.

Sending straight from the VPS is where this goes wrong. A fresh IP address has no sending reputation, and many hosts keep outbound port 25 closed until you ask them to open it. Relay through a mail provider instead, which is the same decision every other service on the box faces: getting mail out of a self-hosted app without landing in spam covers the setup once for all of them. If you want to own the mailbox as well, a Mailcow mail server on a VPS gives you the inbox that the helpdesk polls, though it is a larger project than the helpdesk itself.

Customer support, or an internal IT service desk?

These are two different data models wearing similar interfaces, and the difference decides your shortlist.

In customer support the requester is an email address. Identity is weak, volume is spiky, and success means a reply reaching a person who will never log in to anything you run. Web forms, canned replies and per-department queues matter here. Assets do not.

In an internal service desk the requester is an employee, usually pulled from a directory over LDAP (lightweight directory access protocol), and the ticket points at a thing: a laptop, a licence, a virtual machine. That thing lives in a CMDB (configuration management database) or an inventory, and half the value of the tool is knowing which ticket touched which machine.

GLPI and iTop are built for the second model. FreeScout and osTicket are built for the first. Zammad serves customer support well and can run an internal desk, without asset records. Crossing that line later is the expensive mistake in this category, because the data model is the part you have to migrate, and the theme is not.

How many agents will ever log in?

Nothing in this post charges per agent, so the count does not change your bill. It changes how much structure you have to build before the first ticket.

At two agents, structure is the problem rather than the solution. You want a shared view of one mailbox, a way to show who is handling what, and a history you can search. FreeScout fits that exactly. osTicket fits when customers submit through a form on your site.

At ten or twenty agents you need queues or departments, assignment rules, permission levels, and reporting that shows where work is stuck. osTicket, Zammad and GLPI all ship this. Configuring it is a day of work, and skipping the configuration produces the familiar failure where everything lands in one queue and nobody owns anything.

Do you need SLAs, assets, a knowledge base or approvals?

Take these one at a time, because each one shortens the list.

An SLA clock measures response and resolution time against a target, so it needs business hours, a priority scheme and an escalation path. osTicket ships SLA plans, Zammad ships SLAs, and both GLPI and iTop treat service level management as a first-class part of the model.

Asset tracking means GLPI or iTop. GLPI includes its own inventory of machines next to the service desk. iTop is a CMDB with ticketing built on top, so it wins when the relationships between services and hardware are the point of the exercise. Znuny and OTOBO can add CMDB features from their ITSM packages.

A knowledge base is common but not universal. Zammad includes one, switched off until an administrator enables it. osTicket has FAQs. GLPI has a knowledge base tied to its service desk. FreeScout sells its knowledge base as a paid module.

Approval steps and change management are a smaller club: iTop and the OTRS descendants. When work cannot start until somebody signs it off, look there first and accept the extra weight that comes with it.

Live chat is a different job from a ticket

If what you want is a shared inbox with live chat on your website, stop reading ticketing comparisons and go straight to running Chatwoot as your support desk.

The difference is the state machine. A Chatwoot conversation is a stream of messages with a person attached, tuned for answering quickly across several channels. A ticket is a record with a status, an owner, a queue, a due time and a history you can report on, tuned for work that outlives the conversation. Chasing a hardware replacement across four days is ticket work. Answering 'where is my order' in ninety seconds is chat work.

Plenty of teams want both. Running both means two inboxes and two sets of notifications, so pick the one that matches most of your incoming volume and let the other channel feed it by email.

The options that are worth your time

FreeScout: a shared inbox that behaves like a helpdesk

Licensed AGPL-3.0, written in PHP on the Laravel framework, and released constantly: version 1.8.236 shipped on 24 August 2026. Its documentation states that there are no minimum CPU or RAM requirements and that it runs on shared hosting. The core is free with unlimited agents and tickets, and a long list of extras (knowledge base, workflows, live chat, tags) are paid modules sold as one-time lifetime licences for a single instance. Choose it when mail is the channel and the team is small.

osTicket: the classic form-and-queue ticket system

GPL-2.0, PHP 8.2 to 8.4, MySQL. Version 1.18.4 was published in June 2026, so it is maintained at a slow and steady pace. You get departments, help topics, custom forms, canned responses and SLA plans. The interface looks its age. Choose it when customers open tickets through a form, you want conventional queues, and the box is cheap.

Zammad: the full desk, if you can pay for it in RAM

AGPL-3.0, Ruby on Rails, with the 7.1 series current in August 2026. The self-hosted software is free to run. The subscriptions on Zammad's pricing page are support contracts, starting at 2,999 euros a year for the Business tier as of August 2026. Zammad's own hardware page asks for two CPU cores and 6 GB of RAM, plus 4 GB more if Elasticsearch runs on the same server. Elasticsearch is optional, and it is also what makes search across years of old tickets fast. Choose Zammad when you have real volume, several channels, and a server that can carry it.

GLPI: an IT service desk with the inventory attached

GPL-3.0, PHP 8.2 or newer, MySQL 8.0 or MariaDB 10.6 and up, with release 11.0.8 in June 2026. Mail becomes tickets through a receiver plus the mailgate automatic action, and routing rules can send messages into different entities, which is how GLPI models separate sites or client organisations on one install. Choose it for internal IT where the asset list matters as much as the queue.

iTop: a CMDB with ticketing on top

AGPL-3.0, currently 3.2.3-2 from August 2026. Its own sizing guidance starts at 4 GB of RAM for under 200 tickets a month with fewer than 20 console users, and moves to 8 GB up to 5,000 tickets a month. Choose it when you are modelling services, contracts and impact, and the ticket is the smallest part of that picture.

Znuny and OTOBO: the OTRS line, still maintained

Both descend from OTRS Community Edition, which reached end of life at the end of December 2020. Znuny (GPL-3.0) continues the 6.0.30 codebase and is on the 7.3 series. OTOBO (GPL-3.0) forked in 2019 and is on the 11.0 series. Both are Perl, both are shaped by ITIL practice, and both are heavy: OTOBO's documentation asks for 8 GB of RAM and 40 GB of storage for a production machine, with 16 GB recommended. Choose one when you need process automation and a ticket model built for a service organisation, and somebody on the team is comfortable with Perl.

Two more worth knowing about

Request Tracker (GPL-2.0, Perl) released 6.0.3 in May 2026, and email is its native interface rather than an add-on, which still makes it a good fit for mail-driven queues. Frappe Helpdesk (AGPL-3.0) shipped 1.29.0 in August 2026 and has the most modern interface here, with SLAs and a knowledge base, but you inherit the whole Frappe stack, which means Redis and background workers running alongside the database.

What each one asks of a small VPS

The published minimums are the honest starting point. These are the projects' own figures, not measurements of mine.

[
  {
    "tool": "OTOBO 11",
    "min_ram_gb": 8,
    "notes": "production minimum, 16 GB recommended, 4 GB for a test box"
  },
  {
    "tool": "Zammad 7",
    "min_ram_gb": 6,
    "notes": "add 4 GB more to run Elasticsearch on the same server"
  },
  {
    "tool": "iTop 3.2",
    "min_ram_gb": 4,
    "notes": "under 200 tickets a month, fewer than 20 console users"
  }
]

Read those 3 figures as a floor rather than a target, because each one assumes a modest ticket rate. RAM is also only half the story. Every option here needs a database, and the database wants its own memory budget, so a 4 GB box running Zammad is really a 4 GB box running Zammad, PostgreSQL and whatever else you put on it.

FreeScout and osTicket publish no RAM minimum at all. That is not marketing. They are ordinary PHP applications talking to MySQL, so their floor is set by PHP and the database rather than by the helpdesk, and that floor sits well below the numbers above. Check the disk instead: attachments grow faster than anyone plans for, because customers send screenshots.

How do you know the project is still maintained?

Check this before the feature list, because a dead helpdesk holding customer data is a problem you cannot fix with configuration.

• Read the licence in the repository, not on the marketing page. UVdesk's community package is under OSL-3.0, a licence most teams have never reviewed, and its last release was v1.1.8 in September 2025.
• Look at the date of the newest release, not the newest commit. A commit can be a typo fix in the README.
• Check whether the repository is archived. Peppermint, an open source helpdesk that turns up in a lot of lists, was archived by its owner on 17 July 2026, and its last release was 0.5.5 in November 2024. An archived repository is read-only, so nobody is shipping a security fix for it.
• If the project forked from something dead, check the fork is alive. Znuny and OTOBO both are, with releases through 2026.

When you should not self-host this at all

Be honest about the size of the team. Two people answering a handful of messages a day do not need a ticket system. They need a shared mailbox, labels, and an agreement about who answers what. A helpdesk adds a database to back up, a mail integration that breaks silently, and an application to keep patched, and it answers no tickets for you.

Self-host when you have a reason: data that must stay on infrastructure you control, or per-agent pricing that has become the largest line in your tooling budget. A customisation nobody sells counts too. Those are good reasons, and the tools above are genuinely good.

Do not self-host for cost alone at small scale. A ticket system stores customer names, addresses, order details and complaint history, so patching is not optional and backups have to be restored at least once to count. The hosted plan you resent paying for includes deliverability, upgrades and somebody else's on-call rota. At two agents that is usually the better trade, and the decision is easy to revisit when the queue grows.

The work you are signing up for

Plan the backup before the install. You need the database and the attachment directory, and you need to restore both once on a spare box to know the backup works.

Run it with Compose so an upgrade is a version bump and a restart. If Compose is new to you, the Docker Compose basics for a VPS cover the file layout and which volumes to name. Keep the database in a named volume rather than inside the container, or an upgrade will take your tickets with it.

Watch the mail fetcher, because that is the part that fails quietly. A ticket that never arrived raises no alarm, and the first sign is an angry customer asking why nobody replied. Send a message through the support address every week and confirm it appears. Better, alert on it: a push notification to your own phone when the fetch job stops beats a dashboard nobody opens.

Finally, look at what the tickets are about. When most of them are the same question from different people, a forum you host yourself answers it once in public. When most of them are about payments and dates, better records may solve more than a support desk will, and the self-hosted invoicing tools are the closer fit.

FAQ

Can I run a self-hosted helpdesk on a 2 GB VPS?

Yes, if you pick a PHP application. FreeScout's documentation states there are no minimum CPU or RAM requirements, and osTicket publishes none either, so the floor is whatever PHP and MySQL need on your box. Zammad and OTOBO are the opposite case: their own documentation asks for 6 GB and 8 GB of RAM before you add Elasticsearch. Give those two a server of their own.

Do I need my own mail server to turn email into tickets?

No. Every option here logs in to a mailbox you already have, over IMAP or POP3, and sends replies out through SMTP. A mailbox at your current provider is enough. What you do need is authorisation for the sending address: an SPF record covering whatever relays the mail, DKIM signing, and a DMARC record that agrees with both. Without them the replies are filed as spam, and the ticket looks answered from your side of the screen.

Should I use Chatwoot or a ticket system?

Use Chatwoot when the work is conversations: live chat on a website, social channels, a shared inbox answered in minutes. Use a ticket system when the work has a status, an owner and a due time, and when it outlives the conversation that started it. Escalation, approvals and SLA clocks belong to tickets. If both apply, start with the one that matches most of your incoming volume and route the other channel into it by email.

How do I check a helpdesk project is still maintained?

Open the repository and read the date on the latest release, then confirm the repository is not archived. Peppermint was archived by its owner in July 2026 and its last release dates from November 2024, and an archived repository is read-only, so no security fix is coming. Then read the licence file in the repository rather than the licence claimed on the website, because some projects here use terms you may not have reviewed before, such as UVdesk's OSL-3.0.

Which one should a small team pick by default?

If email is the channel and there are fewer than five agents, start with FreeScout, because it is light, it is released often, and it matches how a small team already works. If customers should open tickets on a form and you want departments and SLA plans without much RAM, start with osTicket. If the tickets are about company hardware, start with GLPI so the asset inventory and the queue live in one place.