osTicket: a PHP support ticket system you deploy from a git clone
The osTicket open source ticketing system official project repository, for versions 1.8 and later
At a glance
- What is it?
- osTicket turns email, web forms and phone intake into a shared agent queue. It runs on PHP 8.2 to 8.4 with MySQL 5.5 or newer, installs through a git clone plus manage.php deploy, and carries GPL-2.0 terms.
- Who is it for?
- Adopt osTicket if you already run PHP and MySQL, want the ticket data on your own server, and can accept that email intake is the primary channel. Do not adopt it if you need a hosted product with no server work, or if you expect a version 2.0 release, which the repository does not contain.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 104 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 27, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What osTicket actually replaces in a support desk
The README describes a three step flow: users create tickets through a website, email or phone; incoming tickets are saved and assigned to agents; agents work the issues to resolution. That is the whole product promise. It is a shared queue with a web interface, not a helpdesk platform with a marketplace of add-ons.
The audience is narrow and identifiable. osTicket suits an internal IT team, a small hosting provider, or a university department that already runs Apache or IIS with PHP and MySQL and wants ticket data inside its own network. The README calls it an alternative to higher-cost customer support systems and describes the setup as simple and lightweight. That framing matters: the project assumes you have a server and someone who can configure it.
It is the wrong tool for a team with no server. There is no managed cloud edition in this repository. The homepage points to documentation, a forum and commercial support, so paid help exists, but the software itself arrives as source you deploy.
How tickets move from intake to an agent queue
The repository layout shows the architecture directly. The root holds entry points such as index.php, open.php, tickets.php, view.php and ajax.php, while scp/ contains the staff control panel, api/ exposes an HTTP API, include/ holds the shared libraries, and setup/ holds the installer. Configuration lives in main.inc.php and client.inc.php, and bootstrap.php wires the request lifecycle.
Intake is channel based. Email arrives through PHP's imap extension, which the README lists among recommended extensions, so the mail poller runs as part of the PHP application rather than as a separate daemon. Web forms post into the same ticket tables. Once a ticket exists, it is assigned to an agent and appears in the staff panel. Attachments are stored on disk and served through file.php, which is why the upgrade guide tells you to back up attachment files separately from the database.
The API surface is real but thin in the README. The api/ directory exists at the top level and the README does not document endpoints, authentication schemes or payload shapes. Anyone planning to build an integration should read the source under api/ rather than expect a specification in the repository root. That is a documentation gap, not a missing feature.
Installing osTicket from the repository and opening a first ticket
The README recommends cloning the public repository as the way to install and track updates. Create an empty folder on the web server and clone into it. The README is explicit that the folder must be empty.
git clone https://github.com/osTicket/osTicketCloning gives you the source tree on the develop branch by default. Next, deploy the code into a location your web server can serve. The README uses /var/www/htdocs/osticket/ as the example target.
cd osTicket
php manage.php deploy --setup /var/www/htdocs/osticket/The --setup flag prepares the deployment for installation. After the command completes, configure your server to serve that folder and visit the page. The README says to install osTicket as usual, which means the web installer under setup/ runs the database and configuration steps. When installation finishes, the README suggests deleting the setup/ folder from the deployment location.
Updates follow the same path from the clone. Pull the new code, then deploy again with verbose output.
git pull
php manage.php deploy -v /var/www/htdocs/osticket/Before any upgrade, the README says to back up attachment files, the database and the codebase. The UPGRADING.txt file and the online Upgrade Guide carry the detailed steps, and the README states that upgrading is supported from 1.6-rc1 and later.
The hosting requirements are the real adoption cost
osTicket does not run on shared hosting with an arbitrary PHP version. The README requires PHP 8.2 through 8.4, with 8.4 recommended, the mysqli extension, MySQL 5.5 or greater, and either Microsoft IIS or Apache as the HTTP server. Those are hard floors. A host still on PHP 8.1 cannot run the current code without upgrading the runtime first.
The recommended extension list is long: ctype, fileinfo, gd, gettext, iconv, imap, intl, json, mbstring, Zend OPcache, phar, xml, xml-dom and zip, plus APCu configured for PHP. Several of these are optional in name only. Without imap there is no email intake, which is the channel most teams care about. Without gd or mbstring, parts of the interface and attachment handling degrade. A minimal PHP build will install and then fail in ways that are not obvious from the installer.
This is the case where osTicket is the wrong tool: a team that wants tickets without owning a runtime. Every upgrade of PHP or MySQL is now your maintenance event, and the project's own upgrade path assumes you can run php manage.php deploy against a live web root.
Where osTicket stops and a different tool starts
The clearest alternative in the same space is a hosted SaaS helpdesk, and the difference is architectural rather than cosmetic. A hosted product terminates your email at its own infrastructure, stores tickets in its own database, and ships changes continuously without a deploy step. osTicket terminates email through your PHP process using the imap extension, stores tickets in your MySQL instance, and changes only when you run git pull followed by manage.php deploy. You trade operational work for data locality and for the ability to modify the code under GPL-2.0.
Within self-hosted options, the meaningful split is language and runtime. osTicket is PHP with a server rendered interface; a Python or Node based helpdesk would let a team standardise on a runtime it already operates. If your organisation has no PHP footprint, adopting osTicket means adopting PHP, its extension set and its upgrade cadence. That is a larger commitment than the ticket features suggest.
One repository detail worth noting for anyone comparing tools: the README's dependency list includes PEAR packages and jQuery dropdown, marked in the README as Project Deleted. The project still lists it as a bundled dependency. That is the kind of thing that ages quietly in a long-lived PHP codebase.
Releases, licensing and what an upgrade costs you
The most recent releases in the repository are v1.18.4 and v1.17.8, both published on 2026-06-17, with v1.18.3 earlier on 2026-01-15. Two maintained lines exist in parallel, which is useful if you are pinned to an older branch, and it also means security fixes have to be tracked per line. The last push to the repository was on 2026-06-17.
Upgrading is a manual operation by design. There is no package manager step and no automatic migration daemon. You pull, deploy, and work through the Upgrade Guide, having backed up attachments, database and code first. The cost is not the command; it is the backup, the staging check and the window during which the deploy writes into the live web root.
The licence is GPL-2.0, with LICENSE.txt in the repository. The practical consequence is that if you distribute a modified osTicket, the GPL's terms attach to that distribution. Running it internally for your own support desk is a different situation from shipping a modified version to customers. This is not legal advice; read LICENSE.txt and, if you plan to redistribute, talk to someone qualified. Localisation is handled separately through Crowdin, and language packs are downloaded from the osTicket download page rather than bundled in the repository.
Editorial conclusion
Adopt osTicket if you already run PHP and MySQL, want the ticket data on your own server, and can accept that email intake is the primary channel. Do not adopt it if you need a hosted product with no server work, or if you expect a version 2.0 release, which the repository does not contain. Before committing, verify three things on your own host: that PHP is 8.2 to 8.4 with mysqli enabled, that MySQL is 5.5 or greater, and that the deploy target folder is empty, because manage.php deploy writes a full tree into the path you pass it.
Frequently asked questions
What does osTicket do?
It collects support requests from a website, email or phone into one queue and assigns them to agents, who resolve them through a multi-user web interface. The README describes the flow as intake, assignment, resolution.
How much does osTicket cost per month?
Nothing in the repository indicates a subscription. The README states the software is completely free and released under GPL-2.0, and the homepage points to optional commercial support if you want paid help managing an installation.
How do I install osTicket?
Clone the repository into an empty folder, then run php manage.php deploy --setup with your target path, serve that folder, and complete the web installer. The README recommends deleting the setup/ folder afterwards.
How do I use the osTicket API?
The repository has a top-level api/ directory, but the README does not document its endpoints, authentication or payloads, so the source under api/ is the reference. Plan to read it before building an integration.
What are the pros and cons of osTicket?
The README's stated advantages are that it is free, open source, web-based and simple to set up, and that it unifies email, phone and web intake. The trade-offs come from its requirements: you must run PHP 8.2 to 8.4 with mysqli and MySQL 5.5 or newer, on Apache or IIS, and you handle every upgrade yourself.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/osticket-osticket)