MantisBT is a PHP bug tracker you install on your own web server and upgrade by hand

A tracker you host, written in PHP

MantisBT is a bug tracker with a long history, and the README is written for an administrator rather than a developer, which tells you what kind of project this is. It is a web application you install on a server you control, and the documentation to read is the administration guide included with the release in the doc/<lang> directory, available in text, PDF and HTML formats.

The requirements are short and specific. A database, either MySQL 5.5.35 or later, PostgreSQL 9.2 or later, or another supported database. PHP 8.1.0 or later. And a web server, with Apache and IIS given as examples. The README points to section 2.2 of the administration guide for the details.

That is the whole stack, and it is worth naming what it implies. There is no cloud service, no container image and no managed database in the documentation. You provision the PHP runtime and the database, you point a web server at the unpacked source, and you own the upgrades and the backups from then on.

The home page is mantisbt.org, the detailed documentation lives at mantisbt.org/docs, and the repository carries a build status badge for the mantisbt workflow, a Gitter room and a SECURITY.md, a KEYS.md and a CONTRIBUTING.md. The last push was on 2026-10-17, and the repository is not archived, so the code is being worked on even though the project publishes no GitHub releases.

Installation ends with deleting the admin directory

The install sequence is short and has one instruction that is easy to skim past and important to follow.

You extract the tarball into a location readable by your web server. Then you open https://example.com/mantisbt/admin/check/index.php to verify that the web server is compatible with MantisBT and configured correctly. Then you open https://example.com/mantisbt/admin/install.php to start the database installation process, where you select the database type and enter the credentials to access the database, and click install or upgrade. Installation is complete, and you may need to copy the default configuration to mantisbt/config/config_inc.php if your web server does not have write access.

Then the last step: remove the admin directory from within the MantisBT installation path. The scripts within that directory should not be accessible on a live MantisBT site, or on any installation reachable over the internet.

That step exists because the install and check scripts are powerful by construction. They create the schema and they read and write the configuration, so leaving them in the web root means anyone who can reach the URL can attempt to re-run the installation. The same instruction appears in the upgrade procedure, which tells you to point the browser at admin/check/index.php and then admin/install.php again, and then to remove the admin directory once more.

A file based install with a two step check, an explicit schema step and a manual cleanup is a different shape from a package manager install, and the cost of that shape is that you are the one who has to remember the last step.

Upgrading means a clean directory, not an overwrite

The upgrade section is the part of the README that most directly describes the cost of running this yourself, and it is blunt about two things.

The first is the backup. Backup your existing installation and database, with the punctuation doing some of the work. The second is the extraction. Extract the tarball into a clean directory, and do not extract into an existing installation, because some files have been moved or deleted between releases.

The reason for the clean directory is that this application stores its configuration and its customisations inside the same tree as the code, so an in-place upgrade leaves a mixture of two versions. The documented procedure avoids the mixture by making the new directory clean and then copying the configuration across deliberately.

The list of files to carry over is explicit, and it is the list you would need for any customisation you have made.

config_inc.php
custom_strings_inc.php
custom_relationships_inc.php
custom_functions_inc.php
custom_constants_inc.php

The last two of those are conditional, the README says if they exist. After copying, you point the browser at admin/check/index.php to confirm the web server is still compatible, then at admin/install.php to upgrade the database schema, click install or upgrade, remove the admin directory again, and the upgrade is complete.

So a MantisBT upgrade is a file operation plus a schema migration, on a schedule you choose. There is no rolling upgrade and no blue green option here, which is the price of the model where the application, its configuration and its database schema all live on the same box.

config_inc.php survives an upgrade, config_defaults_inc.php does not

The configuration section explains a split that makes the upgrade procedure work, and it is the kind of detail that separates a tracker you can maintain from one you cannot.

config_defaults_inc.php contains the default values for all the site wide variables. config/config_inc.php is where you change the values, and your values from that file are used instead of the defaults. The critical sentence is this file will not be overwritten when you upgrade, but config_defaults_inc.php will. The README also points at config/config_inc.php.sample as an example.

So there is a two layer configuration, an upstream layer you never touch and a local layer that survives every upgrade. That is why the upgrade instructions tell you to copy config_inc.php into the new directory. The defaults file is regenerated on every upgrade, so a change to it would be lost, while your own file is carried forward.

The rest of the configuration section is about the shape of the code, and it is unusually explicit for a README. core/*_api.php files contain all the API library functions. Global variables are prefixed by g_, parameters in functions are prefixed with p_ and should not be modified within the function, form variables are prefixed with f_, variables that have been cleaned for database insertion are prefixed with c_, temporary variables are prefixed with t_, and count variables have the word count in the variable name. The coding guidelines are published separately at mantisbt.org/guidelines.php.

The file organisation follows the same philosophy. The files are split into three basic categories, viewable pages, include files and pure scripts, the viewable pages have the suffix _page, and the approach is to break the work into many small files rather than have a small number of really large files. You can also set $g_top_include_page and $g_bottom_include_page to alter what is visible at the top and bottom of each page, which is how a site gets its own header and footer without touching the core.

The REST API is generated from an OpenAPI file

The repository root shows a much larger surface than a plain PHP application would, with files for account management, billing, bug action groups, bug relationships, bug monitors, sponsorship, and a set of api/ and admin/ directories. The API is not hand written documentation, and the tooling in package.json shows how it is produced.

{
  "private": true,
  "scripts": {
    "api:validate": "redocly lint api/rest/mantisbt_openapi.yaml",
    "api:generate": "node tools/openapi/generate.mjs",
    "api:postman": "node tools/openapi/generate.mjs --postman",
    "api:bruno": "node tools/openapi/generate.mjs --bruno",
    "api:docs": "node tools/openapi/generate.mjs --docs"
  },
  "devDependencies": {
    "@redocly/cli": "^2.57.0",
    "openapi-to-postmanv2": "^6.3.3",
    "yaml": "^2.9.1"
  }
}

So the specification lives in api/rest/mantisbt_openapi.yaml, it is linted with redocly, and a generator script produces the client facing artefacts: a Postman collection, a Bruno collection, and documentation. The package is marked private, so these are development scripts rather than a published node package, and the dependencies are Redocly's CLI, the Postman converter and a YAML parser.

Token management sits alongside it in the repository root, with api_token_create.php, api_token_revoke.php and api_tokens_page.php, which is the mechanism by which a script or an integration authenticates against the tracker.

For a team, this is the part that decides whether the tracker is usable in a modern workflow. If your deployment pipeline, your chat bot or your release notes are generated from the tracker, an API defined in one specification and exported into the client your team already uses is the difference between integration and copy and paste.

Editorial conclusion

MantisBT fits a team that wants a self hosted tracker it controls, with no per user pricing and a plain PHP stack any sysadmin can run. It is the wrong choice for an organisation that needs a modern issue workflow with sprints and integrations out of the box, or that does not want to own a web server and a database. Verify first which PHP version and database your host provides, since the requirements are PHP 8.1 and up with MySQL 5.5.35 or PostgreSQL 9.2, and read the administration guide in doc/<lang> before the first upgrade, since the upgrade path depends on replacing the directory rather than unpacking over it.

Frequently asked questions

Official sources

1. Issues
2. mantisbt/mantisbt on GitHub
3. Project website
4. README