Open-source issue tracking, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

What it is: Open-source (GPL-2.0) enterprise ticketing system — think Zendesk or Jira Service Management, but written in Perl, self-hostable, and free to use at any scale [README][5].
Who it’s for: IT departments at universities, government agencies, and mid-size organizations with Linux sysadmin capacity and complex workflow requirements. Not for non-technical founders [5].
Cost savings: Zendesk Suite starts at $55/agent/month. Freshdesk paid plans run $15–$79/agent/month. Jira Service Management is $17.65/agent/month. Request Tracker software is $0, plus your server cost ($5–20/mo) [5][pricing page].
Key strength: Extremely customizable — queues, custom fields, roles, lifecycle workflows, scrips, and SLA rules. Organizations with unusual workflows that no SaaS vendor accommodates cleanly have been running RT for two decades [5][website].
Key weakness: Written in Perl and requires Apache/nginx with FastCGI or mod_perl, CPAN module installation, and a real database setup. The setup process is closer to deploying old-school Linux infrastructure than launching a Docker container. The UI, despite a Bootstrap refresh in RT 5, still looks like 2008 to most people [5].

What is Request Tracker

Request Tracker (RT) is a ticket-based workflow management system built by Best Practical Solutions LLC. It has been in production use for more than 20 years — which means it predates GitHub stars, Docker, and the entire concept of “deploy in 5 minutes.” Its GitHub repository sits at 1,106 stars [merged profile], which is not a reflection of adoption so much as a reflection of its age: most of its installed base was configured before sharing GitHub links was how you talked about software.

The core pitch has not changed much: you have queues, tickets flow through queues, staff respond via email or the web interface, and administrators define what happens at every step via configurable rules called Scrips [README]. A Scrip says: when this condition happens on this ticket, take this action. That sounds simple but scales to complex operational logic that most SaaS help desks can’t replicate without expensive enterprise add-ons.

RT is licensed under GPL-2.0, which means free to use and modify, but you cannot embed it in a proprietary product without releasing your source. For internal use by an IT department, support team, or operations group, the license is not a practical constraint [README][merged profile].

The software is commercially-supported by Best Practical Solutions, who sell hosting, support contracts, training, and custom development [README]. The open-source code and commercial vendor being the same organization is a stable arrangement — there’s no “community vs. enterprise edition” bait-and-switch, just one GPL codebase you can either run yourself or pay them to run for you.

Why people choose it

The common thread across the users who reach for RT is: their workflow doesn’t fit what off-the-shelf help desks assume. RT gets chosen when [5][1]:

Email is the primary communication channel and must be treated seriously. RT’s email integration is the one feature competitors consistently struggle to replicate at this depth. Any email sent to a configured address (support@, helpdesk@, security@) becomes a ticket. Replies from staff go out with proper threading. Customers can reply to those emails and the replies land on the correct ticket. This sounds like a basic feature in 2026, but getting email threading right across diverse mail clients and relay configurations is actually hard, and RT has had 20 years to work out the edge cases [website][5].

Configuration over convention. Every aspect of RT is configurable — queues have their own lifecycles, access controls, custom fields, and notification rules. An organization running separate queues for IT support, HR requests, and vendor invoices can give each queue entirely different states, roles, and automations without touching the code [website][5]. Appmus [5] describes this as a system that “can be adapted to a wide range of use cases beyond traditional IT support” — change management, legal intake, procurement — all have been built on RT using its lifecycle editor and custom roles.

Cost at scale. When you have 50 agents and you’re looking at $2,750/month for Zendesk Suite, the math for self-hosting becomes very clear very fast. The software cost is zero. A modest server handles thousands of tickets per day [5][website].

Long-term stability. Universities and government agencies running RT installations from 2005 are still running them today, upgraded, because the data model has been stable enough to migrate across major versions. That kind of continuity is hard to find in any software category, let alone customer support tools [5][website].

Features

Core ticketing:

Unlimited queues with per-queue custom lifecycles, rights, and configurations [website]
Unlimited custom fields on tickets, assets, and users [website]
Custom roles on tickets and assets to associate users and groups [website]
Full email integration — inbound and outbound, with threading [website][5]
Drag-and-drop attachments via web or email [website]
Inline editing in ticket lists and display pages [website]

Automation:

Scrips system: every transaction on a ticket triggers configured Scrips; each Scrip has a Condition, Action, and Template [website]
Visual Lifecycle editor (added in RT 5) for designing workflow states in the browser [website]
Scheduled reports and dashboards [website]
SLA management [5]

Search and reporting:

Transaction Query Builder — search individual transactions (“show me all replies sent by the Support queue last week”) [website]
Charts interface for data visualization [website]
Advanced query builder [website]
Saved searches and dashboards with drag-and-drop layout editor [website]

Collaboration and knowledge:

Articles (knowledge base): canned responses, FAQs, insertable into ticket replies [website]
Time tracking — estimated and worked, built-in on every ticket [website]
Asset management — track hardware, software, and other assets linked to tickets [website]

Administration:

RT Configuration in Web Admin UI — hundreds of config options editable in-browser by superusers [website]
Fine-grained rights system — grant access per user, per group, per queue [website]
REST 2 API with token auth and JSON, plus Zapier integration [website]
Bootstrap-based theme builder for custom branding [website]
Multi-language UI [5]

Extensibility:

Plugin architecture with a large CPAN extension library [5]
Active extension ecosystem: RT-Extension-TimeTracking, RT-Extension-ChangeManagement among the commonly cited [website]
Full-text indexing support in MySQL, MariaDB, PostgreSQL, Oracle [README]

Pricing: SaaS vs self-hosted math

Request Tracker software: $0 (GPL-2.0). No per-agent fees, no per-ticket fees, no plan tiers for the software itself [README][website].

Commercial hosting and support from Best Practical: pricing is not listed publicly — you contact sales. Based on the audience (IT departments, universities, enterprises) the expectation is enterprise contract pricing, not a monthly credit card charge [website].

Server cost to self-host: $10–30/month on Hetzner, DigitalOcean, or Contabo for a VPS that handles a small to mid-size team. RT is not lightweight — it’s a Perl application with persistent processes, and under moderate load you’ll want at least 4GB RAM.

Commercial alternatives for comparison:

Tool	Pricing
Zendesk Suite	$55+/agent/month
Freshdesk Growth	$15/agent/month
Freshdesk Pro	$49/agent/month
Jira Service Management	$17.65/agent/month (Cloud)
osTicket	Free self-hosted
Zammad	Free self-hosted

For a 10-agent support team: Zendesk runs $550/month, $6,600/year. Freshdesk Growth runs $150/month, $1,800/year. RT on a $20/month VPS runs $240/year.

The savings math is real. The cost you’re not pricing in is setup time and ongoing Perl/Linux maintenance. If your organization already has sysadmin capacity, RT is the cheapest option by a significant margin at any agent count. If you don’t, those savings can evaporate in contractor hours [5].

Deployment reality check

This is where Request Tracker genuinely diverges from every other tool in this review series: the installation process is pre-Docker-era Linux sysadmin work.

What you actually need:

A Linux server (Perl 5.26.3 or later required) [README]
A supported database: MySQL 8.0.31+, MariaDB 10.6+, PostgreSQL 13+, or Oracle 18c+ [README]
Apache 2.x with mod_fcgid or mod_perl, OR nginx with FastCGI [README]
CPAN Perl module installation — RT ships a helper script that automates most of this, but it still pulls dozens of modules from CPAN [README]
A TLS certificate (Let’s Encrypt works) [README]
Comfort with editing Perl configuration files (etc/RT_SiteConfig.pm) [README]

What the install process actually looks like:

You unpack a tarball, run ./configure with flags (RT installs to /opt/rt6 by default), run the CPAN module installer, initialize the database, configure your web server to proxy to RT’s FastCGI handler, and edit the site config file. It’s not a wizard. There’s no “click next, it works.” The documentation at docs.bestpractical.com is thorough, but you’re reading documentation, not following a Docker Compose file [README].

Realistic time estimates:

Experienced Linux admin who has done this before: 2–4 hours to a working instance
Developer comfortable with Linux but new to RT: full day, possibly two
Non-technical founder following a guide: this is the wrong tool

What can go sideways:

CPAN dependency resolution can fail on certain OS configurations — you may need to manually install OS-level packages before Perl modules will compile [README]
mod_perl and Apache configuration has a lot of edge cases; FastCGI is the more forgiving path [README]
Email integration requires configuring your mail server to pipe or forward incoming mail to RT’s mail handler — this is not a trivial step if you’re not managing your own mail [website]
Upgrades between major versions (RT 4 → RT 5 → RT 6) require database schema migrations that need testing [README release notes]

Appmus [5] puts it plainly: RT “requires technical expertise for initial setup and complex configurations” and “relies heavily on configuration rather than out-of-the-box simplicity.” That’s accurate. This is not a criticism — it’s a description of the trade-off you’re accepting for unlimited customization.

Pros and cons

Pros

Zero per-agent or per-ticket cost. At any scale, the software bill is $0. For large teams this is a decisive financial advantage over every commercial alternative [README][website].
Email handling is best-in-class. Twenty-plus years of production use across universities, government agencies, and enterprises has stress-tested the email threading implementation in ways most newer tools haven’t been [website][5].
Unlimited configurability. If your workflow is unusual — and most real operational workflows are — RT’s Scrips, custom lifecycles, custom fields, and custom roles can model it. Most SaaS help desks eventually say “that’s not supported” [5][website].
GPL-2.0 with commercial support available. You get the source, the right to modify it, and an option to buy support from the company that built it [README][website].
Mature and stable. An RT installation configured in 2012 is still running today at organizations that depend on it. The upgrade path exists and is documented [website].
Asset management built in. Tracking hardware, software, and other assets linked to tickets is a first-class feature — many help desks charge extra for this [website][5].
Plugin ecosystem. Extensions for change management, time tracking, LDAP integration, and more are available via CPAN and the RT wiki [5][website].

Cons

Perl in 2026 is a staffing problem. Finding someone comfortable debugging a Perl application and its CPAN dependencies is genuinely harder than finding a Node.js or Python developer. When something breaks in production, your options are narrower [README][5].
Setup is not beginner-friendly. No Docker Compose file, no one-click installer. You are configuring a Perl application server [README].
UI shows its age. RT 5 and RT 6 added a Bootstrap-based responsive theme, which is a real improvement, but the interface still feels like something built when IE6 was current. Appmus [5] specifically notes the UI “may feel less modern compared to some commercial alternatives.”
Low GitHub stars relative to age. 1,106 stars for a 20-year-old enterprise tool suggests the active developer community is smaller than you’d expect [merged profile]. Contributions come in slowly.
No cloud-native features. No native Slack integration, no modern webhook system out of the box — integrations are via the REST 2 API or the Zapier connector [website].
Configuration complexity is a double-edged sword. The same flexibility that makes RT powerful makes it easy to misconfigure. There’s a lot of RT in production that works in bizarre ways because someone got the Scrips wrong in 2015 [5].

Who should use this / who shouldn’t

Use Request Tracker if:

You’re an IT department at a university, government agency, or established company with Linux sysadmin capacity already on staff.
You have unusual workflow requirements — multi-queue, complex approval chains, SLA enforcement — that commercial help desks don’t handle without enterprise-tier pricing.
You have 10+ agents and the recurring SaaS bill is a real budget line.
You have someone who can own the installation and care for it. Not a weekend project for a solo founder.
Email is your primary support channel and you need it handled correctly.

Skip it (pick Zammad instead) if:

You want open-source self-hosted help desk but need a modern interface and Docker-based deployment. Zammad covers most of the same use cases with a significantly easier setup [1].

Skip it (pick osTicket) if:

You need something simpler than RT, open-source, and PHP-based (easier to host on shared infrastructure). osTicket has a smaller feature set but installs in an hour [1].

Skip it (pick Freshdesk or Jira Service Management) if:

You don’t have Linux sysadmin capacity and you’re willing to pay per-agent fees to avoid it. The managed cloud options are a legitimate trade-off.

Definitely skip it if:

You’re a non-technical founder building your first company. RT will cost you weeks of setup time and ongoing maintenance overhead that is not worth it until you have dedicated IT staff.
Your team is fewer than 5 people. The configuration overhead exceeds the value at small scale.

Alternatives worth considering

From the alternative.me listing [1] and the broader category:

Zammad — Open-source, modern UI, Docker-based, active development. Easier to set up than RT with most of the same core features. Strong first choice for teams that want open-source without the Perl dependency [1].
osTicket — PHP-based, open-source, simpler than RT. Good for basic helpdesk without complex workflows [1].
Redmine — Better fit for software development teams needing issue tracking alongside project management. More GitHub-native feeling than RT [1].
Jira Service Management — The commercial standard for IT service management. $17.65/agent/month, integrates with the Atlassian ecosystem. Pick this if your team already lives in Jira [1].
Freshdesk — Better UX than RT, free plan for small teams, grows expensive at scale. No self-hosting option [5].
Bugzilla — Open-source bug tracker, not a help desk. More appropriate for development teams than customer support [1].
Trac — Like Bugzilla, development-focused and showing its age [1].

For a non-technical team escaping Zendesk or Freshdesk pricing, the realistic open-source shortlist is Zammad vs RT. Pick Zammad if you want modern and manageable. Pick RT if you need deep email integration and complex workflow rules, and have the Perl expertise to support it.

Bottom line

Request Tracker is real enterprise software that has been solving real problems at real organizations for 25 years. Its email handling, workflow flexibility, and zero software cost are genuine advantages — the kind that justify running it if your organization’s situation matches its strengths. But it is not the kind of tool you deploy on a Saturday afternoon. It requires Perl, a configured web server with FastCGI or mod_perl, CPAN dependency management, and ongoing sysadmin attention. The UI is functional but not modern. The GitHub community is thin relative to newer alternatives.

If you’re a non-technical founder looking to escape a help desk SaaS bill, RT is almost certainly the wrong answer — Zammad or osTicket will get you there with far less operational overhead. If you’re an IT manager at a university or mid-size enterprise with sysadmin staff and complex workflow requirements that no SaaS vendor has been willing to accommodate at a reasonable price, RT is exactly what it’s been for two decades: unglamorous, powerful, and reliable.

If the setup complexity is the blocker, upready.dev deploys and configures self-hosted infrastructure for teams — one-time engagement, you own the server.

Sources

Alternative.me — “21 Best Request Tracker Alternatives - Reviews, Features, Pros & Cons”. https://alternative.me/request-tracker
Appmus — “Request Tracker: Features, Alternatives & Analysis (2026)”. https://appmus.com/software/request-tracker

Primary sources: