This week we launched a redesigned Request Tracker documentation site. Same documentation you rely on, now with updated search and cleaner navigation, all at docs.bestpractical.com. Alongside it, we stood up a separate home for developer documentation at developer.bestpractical.com, so the people extending and integrating RT have a dedicated space built for that work. Together they are a real step up in how you find what you need.
It is also a good moment to say the larger thing the docs belong to. After more than 25 years, Request Tracker is still open source, still self-hostable, and your data is still yours.
That is not the direction the rest of our industry has gone. Across the ticketing and issue-tracking category, prices have climbed and more of the useful parts have moved behind a higher tier or a paid add-on. Per-user pricing is nothing new there; what has changed is that the seats cost more, and the feature you actually need increasingly sits on a plan above the one you are on. If you run one of those tools, you have probably felt the ground shift under a system you did not choose to change.
RT has stayed put on purpose. Every instance gets the full feature set: unlimited queues, custom fields, lifecycles, the REST 2 API, assets, and the deep library of extensions the community and Best Practical have built. You choose your level of scale and support, not which features you are allowed to use. You can run RT on your own servers, on your own AWS account, or let us host it as Cloud RT, and you can move between those without asking permission. You own your data and can export it any time.
There is a reason that matters more every year. Your ticketing system holds the record of how your organization actually runs: what was asked, what was decided, who did it, and when. With many hosted tools, that record lives on infrastructure the vendor controls, under terms the vendor sets, and it may be used to train the vendor’s own models. With RT, the record stays inside an instance you control. Anything you add on top, including AI you bring yourself and run through your own instance, works against data that stays available, portable, and yours.
The documentation is a concrete piece of that same promise. If RT is genuinely yours, you should be able to run it yourself, and that means being able to find answers on your own schedule. Good docs make self-sufficiency the default. Our on-premise support is there when you want an engineer alongside you for the hard upgrade or the strange edge case, and that help has real value. The point is that it should be a choice you make, not the only door to understanding your own system.
To the admins who have kept RT running for years, often as the one person who really understands the config: these docs are for you. You and RT have a long relationship, and it runs in both directions. RT holds your organization’s memory; you hold the knowledge that keeps it healthy. The redesigned docs are meant to strengthen that, so the next upgrade, the next odd edge case, the next thing you touch once a year is faster to figure out.
None of this changes the deal underneath. The code is always free and available, even when we handle the hosting, and your data is always yours to keep and export. The tools around us will keep changing, that commitment will not.
So if you have been putting off an upgrade, this is a good moment to take it on. Start at the redesigned docs, where the upgrade guides are easier to find, helping you plan your move to the latest RT. If the upgrade feels heavy, that is exactly the kind of thing our team helps customers with every day. And if you would rather stop patching servers altogether, we can talk about moving your instance to Cloud RT, with your data still yours and exportable any time. New to RT? Start a free trial with no credit card, or download it and read the source.
Either way, RT stays open and your data is yours. Take a look at the redesigned docs, and if something is still hard to find, let us know!
Leave a Comment