Request Tracker

small businesscommunication

Battle-tested open-source ticketing system with 20+ years of production use. Email-driven queues, custom workflows, SLA management, asset tracking, and 400+ free extensions. Written in Perl

#ticketing#helpdesk#support#email#itil#self-hosted

Quick Start

docker run -d -p 8080:80 --name rt bestpractical/rt:5-latest

Overview

Request Tracker is one of the oldest continuously maintained open-source applications in production use. It has been handling support tickets, IT requests, and operational workflows since 1996. Universities, government agencies, financial institutions, and enterprises have run it for decades. The low GitHub star count reflects a project with a pre-GitHub community, not an inactive one.

The core model is email-driven. You configure RT to receive email from any number of addresses — support@, helpdesk@, billing@, security@ — and every incoming email creates or updates a ticket in the corresponding queue. Agents reply from the RT interface or directly by email, and the full conversation history is preserved on the ticket. PGP and S/MIME encryption for incoming and outgoing email are built in, which matters for teams handling sensitive requests.

Queues and lifecycles are where RT’s configurability shows. Each queue has its own ticket statuses, transition rules, access rights, and SLA definitions. The visual lifecycle editor configures these from the browser. Scrips — RT’s automation system — fire on any ticket event and can trigger email notifications, status changes, calls to external systems, or any custom Perl action. This level of automation depth requires configuration time, but it handles workflow requirements that simpler tools cannot.

Asset management is built into the core, not a plugin. Hardware, software licences, and infrastructure components can be tracked alongside the tickets they generate, with relationships linking an asset to all of its service history.

The RTIR module extends RT specifically for security incident response, adding dedicated queues, investigation workflows, and linkage between incidents, investigations, and countermeasures that security teams need.

The practical reality is that RT is a Perl application from an era when Perl was the language of web development. Customisation and extension require Perl knowledge. The Docker deployment path makes running it straightforward; going beyond the default configuration requires more investment than a PHP or Node.js-based alternative.

Request Tracker: Pros & Cons

Pros (The Wins)Cons (The Friction)
20+ years production use:
Deployed by governments and
universities; extremely stable.
Perl stack:
Customisation requires Perl
knowledge most teams lack.
Email-native:
Full conversation history;
PGP and S/MIME built in.
Dated UI:
Powerful but noticeably older
than modern helpdesk tools.
Deep automation:
Scrips fire on any event;
custom lifecycle designer.
Slow development:
Commercial company behind it;
open-source pace is measured.
400+ free extensions:
Change management, surveys,
time tracking, and more.
Complex to customise:
Beyond defaults, the Perl
architecture is a barrier.

Use Cases

Specific ways to use Request Tracker for your workflow.

01
Route all email sent to support@, helpdesk@, and security@ into a structured queue where nothing gets lost
02
Track IT assets alongside the support tickets they generate — hardware, licenses, and infrastructure in one system
03
Define custom ticket lifecycles with visual workflow stages and automated actions triggered at each transition
04
Run an incident response process with the RTIR module built specifically for security team workflows

Deployment Strategy

Recommended ways to host Request Tracker in your own environment.

docker
self-hosted