# Request Tracker: a self-hosted ticket system that predates the SaaS era

> Request Tracker is a Perl issue and ticket tracking system distributed under GPL-2.0, with the deployment details spelled out down to the database engine, the web server module and the Perl version. It suits organisations that need to run their ticketing inside their own perimeter, and it demands more operational care than a hosted product.

**bestpractical/rt** — Request Tracker, an enterprise-grade issue tracking system

- Repository: https://github.com/bestpractical/rt
- Website: https://bestpractical.com/rt
- Stars: 1,164 · Forks: 296
- Language: Perl
- License: GPL-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/bestpractical-rt

## RT is a Perl application with a configuration-time personality

Request Tracker is described as an open source, enterprise-grade issue and ticket tracking system, and the sentence the project uses about its purpose is precise: it lets organisations keep track of what needs to get done, who is working on which tasks, what has already been done, and when tasks were or were not completed.

The technical shape is a Perl application driven by an autotools style configure script. The distribution is unpacked with tar, configured with `./configure`, and its arguments are stored at the top of `etc/RT_Config.pm` so you can recreate a previous configuration. The defaults are opinionated in a useful way: the install target is `/opt/rt6`, and the default database type is `mysql`.

The default database choice has a wrinkle worth reading twice. The default `--with-db-type` of `mysql` means MySQL 8 and later. Starting with RT 5.0.6, `mysql5` is the value that runs MySQL 5.7 or older, and `MariaDB` is the value for MariaDB. So a fleet on an older MySQL is not on a legacy path, it is on a different flag.

The repository layout reflects the scale of the thing. Alongside `lib/`, `bin/`, `sbin/` and `etc/`, there is a `t/` directory for tests, a `devel/` directory, a `Dockerfile`, per-database readme files named README.MySQL, README.MariaDB, README.Oracle and README.PostgreSQL, and Perl quality tooling in `.perlcriticrc` and `.perltidyrc`.

## The dependency floor is specific and it is not negotiable

Most of the README is a list of what must be present before RT will start, and the version floors are the useful part.

Perl 5.26.3 or later is required, and the project states plainly that RT will not start on older versions. The supported databases are MySQL 8.0.31 or later with InnoDB, MariaDB 10.6 or later with InnoDB, Postgres 13 or later, Oracle 18c or later, and SQLite 3.0 or later, where SQLite is explicitly marked as being for testing only with no upgrade path guaranteed. That SQLite caveat is the kind of sentence that saves someone a migration, so treat it as a hard line rather than an option on a small deployment.

The web layer needs a server with FastCGI or mod_perl. Apache 2.x with mod_fcgid or mod_perl is the documented path, nginx is supported, and any other server with FastCGI support works. One operational note sits in the middle of that list: the FastCGI handler needs access to RT's configuration file, which is the kind of filesystem permission that decides whether the web interface works the first time or after an afternoon.

Optional dependencies are worth planning around too. Full-text indexing is available in the listed databases except SQLite, and an external HTML converter can be installed to improve performance, configured through the `$HTMLFormatter` option.

## Installing from a tarball means configure, testdeps and fixdeps

The installation sequence in the documentation is four steps, and the third and fourth are the ones people miss.

First unpack the distribution somewhere other than where RT will be installed, and the documentation suggests your home directory or `/usr/local/src`:

```bash
tar xzvf rt.tar.gz
```

Then run the configure script, checking `./configure --help` for the option list, and re-run it with the flags you want:

```bash
./configure --help
```

The default install directory of `/opt/rt6` does not work under the default SELinux configuration, which is a detail worth knowing before you diagnose a permissions failure as an RT bug.

The step people skip is dependency checking. RT ships a tool that installs most Perl modules automatically through CPAN, and the documented commands are:

```bash
make testdeps
make fixdeps
```

`make testdeps` reports what is missing, and `make fixdeps` installs it, run as a user with permission to install Perl modules on the system. The documentation is honest that this is not always enough: some modules need user input or environment variables, and some need external source libraries, so system packages may have to be installed as well. Ticket relationship graphing needs the graphviz library, installed with the system package manager.

For a test environment without TLS, the documentation gives one configuration line to add to `etc/RT_SiteConfig.pm`, namely `Set( $WebSecureCookies, 0 );`. Without it your browser will not trust RT's cookies and you cannot log in.

## Upgrades are a documentation path, and RT 6 is a move, not a patch

Because RT versions arrive with database schema changes, the project points upgrading users at a set of version specific documents rather than a single procedure. The upgrade notes live in `docs/UPGRADING-*`, and the README names the ones that matter for the current line.

A move from 4.4.x to 5.0.x to 6.0.x needs three documents read in order: UPGRADING-4.4, UPGRADING-5.0 and UPGRADING-6.0. The documentation also gives a sequencing rule that is easy to skim past. Any steps given in version specific UPGRADING files should be run after the rest of the steps, and you are asked to read the relevant documentation before beginning, to be aware of important changes.

That ordering note implies the schema work happens in the main upgrade flow and the version specific files hold the parts that differ between paths, which is the kind of arrangement that punishes an upgrade done from memory.

Release history shows two parallel lines in the recent past. RT 6.0.3 and RT 5.0.10 were both tagged on 2026-05-20, with 6.0.2 earlier at 2025-10-22. So a 5.0 deployment is still receiving its own patches, and the 5.x line is not a dead branch. The last push was on 2026-10-18 and the repository is not archived.

Licensing is GPL-2.0, and the project states RT costs nothing to use no matter how much you use it. It is also commercially supported, with hosting, support, training, custom development and professional services sold by Best Practical.

## The Dockerfile in the tree is a test harness, not a production image

There is a Dockerfile at the top of the repository, and its first line says what it is for: this Dockerfile is for testing only.

What it builds from is a prebuilt base image rather than from the source tree:

```dockerfile
FROM bpssysadmin/rt-base-debian:RT-6.0.3-trixie-20260723
```

The environment variables are the interesting part, because they show what the test suite expects to exist. `RT_TEST_PARALLEL` and `RT_TEST_DEVEL` are set to 1, `RT_TEST_SMIME_REVOCATION` is enabled, and the database and RT hosts are separate containers at `172.17.0.2` and `172.17.0.3`, with `RT_DBA_USER` set to root and `RT_DBA_PASSWORD` set to password. A user named `rt-user` is added with a disabled password, and the comment says it is required by the mod_fcgid tests. The container's command is `tail -f /dev/null`, which keeps it alive for a test run rather than serving anything.

Two things follow from that file. It confirms the test suite exercises a real database container and a separate RT container over the Docker network, which is a genuine integration test rather than a mocked one. And it makes clear that this file is not a deployment recipe: the credentials are placeholders, the base image is pinned to a specific RT release, and the container serves no traffic. Building your own production image means starting from the source distribution and the install steps above, not from this Dockerfile.

## Where RT does not fit

The obvious case is a small team that wants a working queue quickly. A hosted ticketing product gives you a working system in an afternoon, while RT gives you a Perl application, a database, a web server with FastCGI, a dependency resolution step and a configuration file you are expected to edit. That is a fair trade for control, and a bad one for speed.

The second case is a team that wants a modern interface out of the box. The documentation links a support dashboard screenshot, which tells you the web interface exists, but nothing in the repository describes a component model for a custom UI. Extensions in RT are Perl code inside the application, which is a different integration model from a JSON REST API you can build a separate frontend on. A team whose frontend and backend are separate teams should ask about that split before choosing RT.

The third is operational ownership. Every Perl module, every database upgrade, every security patch and every restore is yours. The project offers paid hosting and support, which changes the shape of the problem but not the responsibility.

The alternative approach is a hosted service, and the difference in approach is straightforward: RT gives you the data model, the permission system, the ticket lifecycle and the audit trail inside your own perimeter, while a hosted service gives you a maintained instance you do not have to run yourself. Where RT is weak, its paid support offering is a genuine route, and where it is strong, nothing else in the open source issue tracker category matches its combination of a long-lived schema, a documented upgrade path across major versions and a mail-centric workflow.

## Conclusion

Request Tracker earns a place in organisations that must keep tickets on their own infrastructure, or that want a system with a long history of enterprise deployment behind it, and the GPL-2.0 terms suit a project willing to carry that licence into a distribution. It is a poor fit for a small team that wants a working queue in an afternoon, since the install path runs through configure, dependency resolution and a web server with FastCGI or mod_perl. Before you commit, read the UPGRADING files for the versions you will pass through, since a 4.4 to 5.0 to 6.0 path spans several documents, and confirm your Perl is 5.26.3 or later and that your database meets the listed minimum version, MySQL 8.0.31, MariaDB 10.6 or Postgres 13.

## FAQ

### What are the system requirements for Request Tracker?

Perl 5.26.3 or later, a supported SQL database, either MySQL 8.0.31, MariaDB 10.6, Postgres 13, Oracle 18c or SQLite for testing only, and a web server with FastCGI or mod_perl support.

### How do I install Request Tracker from source?

Unpack the tarball with `tar xzvf rt.tar.gz`, run `./configure --help` to see the options then re-run configure with your flags, then run `make testdeps` to check for missing Perl modules and `make fixdeps` to install them.

### Which database does Request Tracker use by default?

The default `--with-db-type` is `mysql`, which means MySQL 8 and later. Starting with RT 5.0.6, `mysql5` runs MySQL 5.7 or older and `MariaDB` selects MariaDB.

### Can I run Request Tracker without an SSL certificate?

For testing, add `Set( $WebSecureCookies, 0 );` to `etc/RT_SiteConfig.pm`. Without that setting your browser will not trust RT's cookies and you will not be able to log in.

### How do I upgrade Request Tracker across major versions?

The upgrade notes are in `docs/UPGRADING-*`. Moving from 4.4.x through 5.0.x to 6.0.x means reading UPGRADING-4.4, UPGRADING-5.0 and UPGRADING-6.0, and running the version specific steps after the rest of the upgrade.

## Sources

- [bestpractical/rt on GitHub](https://github.com/bestpractical/rt)
- [License: GPL-2.0](https://github.com/bestpractical/rt/blob/stable/LICENSE)
- [Project website](https://bestpractical.com/rt)
- [README](https://github.com/bestpractical/rt/blob/stable/README.md)
- [Releases](https://github.com/bestpractical/rt/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bestpractical-rt