Try out the best cloud-hosted help desk platform for 30 days

Thank you for signing up for a 30-day free trial!

Please watch our SupportSystem walkthrough video while we process your account.

Your New Journey Begins Here

No Credit Card Required. No obligation, cancel anytime.

Subscribe to osTicket Mailing Lists

Thanks for choosing osTicket. Please subscribe to the osTicket mailing lists to be informed of available upgrades and security patches when they are released.

Download Your osTicket

If your osTicket download does not start within 5 seconds, click the download button above.

Thanks for choosing the world's most popular open source ticketing system. Here's a few pointers on what to do next

Visit our wiki for a detailed outline of installation

No Thanks


Please Wait...


Customizing osTicket (and Why You Should)

osTicket is striving to develop the world’s most popular open source ticketing system more openly. Starting with osTicket 1.7, the mainline development has been available on GitHub. If you are maintaining or creating a customized version of osTicket, using git and following the mainline development’s GitHub repo can make you far more successful.

Follow the Source

GitHub allows you to fork the mainline repository and make custom changes to the software, while tracking the mainline development and allowing you to merge upstream changes into your custom code.

osTicket development can be managed from a git repo — even on a local level on your own server. If you’re customizing osTicket, you should be using git, and you should be following the upstream development. However, you should not be serving the git repo from your web server. The repo should be located somewhere outside the path served from your web server.


You’re probably still reading this article because you want or need to customize osTicket. Customizations are welcome and expected. We are working hard to implement a full extension and plugin system to make modifications easier to port between osTicket versions. In the mean time, you can modify the source directly while still following the upstream activity for big fixes and new features.


Create a GitHub account and fork the osTicket repo. Then, clone the repo onto your web server or add a remote to point to your fork. If you’re super lazy, it is possible to follow the upstream development directly, while still tracking changes locally. For instance, if you manage source code in a folder in the home folder on your box called sandbox, you could do something like this

git clone ~/sandbox/osTicket-1.7

Then, make all the changes you need. Once completed, you can deploy them to the folder where osTicket is installed on your box using the included deployment script.


First, checkout the git repo onto your web server. Then, use the deploy cli module to deploy osTicket for an installation.

php setup/cli/manage.php deploy --setup /path/to/installation

As an added bonus, the deployment script also supports managing a separate location for the include/ folder. See deploy --help for more information. The location of the include path is only necessary on the initial deployment. Thereafter, it is automatically detected.

Follow the general installation directions and delete the setup folder as usual. Then, you can deploy osTicket updates from GitHub similar to the following. Use the command-line and change directories to your git repo path, and then into the setup/cli folder

git pull
php setup/cli/manage.php deploy -v /path/to/installation

Development Guidelines

We encourage you to change osTicket to suit your individual needs. However, be careful not to make changes that will make it difficult or impossible to follow others’ changes including upstream changes made to the mailine osTicket repository


If your customization makes changes to the main osTicket tables, you will likely get merge conflicts when the core stream is updated. If you need to add columns to an upstream table, add another table with the extra columns and link the data to the upstream table using the primary key of the upstream table. This will keep your data model separate from the upstream data model.


If you need the installer or the upgrader to manage database changes outside of osTicket core, you can create a different database migration stream to create and migrate changes to your stream. See the docs for streams in the repo under setup/docs/


After getting your changes initially staged, checked in, and deployed, you can merge changes between your code and another contributor’s or the mainline repo. First, add the repo to your git remotes if it not already in the list of remotes

This process might be done frequently to pull upstream changes. You might add the mainline repo under the name of upstream

git remote add upstream
git fetch upstream

And then merge in the upstream changes into your own

git checkout develop
git merge upstream/develop

If you get merge conflicts, follow the usual git approach. Edit the conflicted files and add them to be staged for a commit. After resolving all the merge conflicts, commit the merge.

git remote add friend
git fetch friend

Then you can merge their changes with your own

git checkout develop
git merge friend/develop


A git how-to is really beyond the scope of this blog post. There are numerous articles concerning how git works and how it is used in this manner. However, once you learn to manage software codebase changes using git, you’ll find it extremely effective to manage your custom changes to osTicket while still maintaining compatibility with upstream osTicket. This affords you the ability to continuously reintegrate your custom changes into the ever-changing osTicket upstream codebase.