MantisBT ships frequent maintenance releases, and several of them close real security holes. The 2.28.4 build released on 1 July 2026 fixed a critical vulnerability (CVE-2026-47156) affecting 2.28.3 and earlier, following similar fixes earlier in the year for the SOAP API and tag-name XSS issues. Staying current is not optional when your tracker is reachable from the open internet, so the practical question becomes how to move to the current stable version without root, SSH, or any server-wide tooling.
The MantisBT upgrade model is well suited to a cautious, file-based workflow. Upstream explicitly recommends extracting each release into a clean directory rather than overwriting an existing install, because files are moved and deleted between versions. The database is migrated separately by a web-based admin script (admin/install.php) that applies schema changes in sequence. Those two facts shape the entire procedure below: you prepare a fresh code tree, carry your configuration and uploaded files across, point the site at the new code, and run the schema migration once. Each of those steps is fully reversible if you capture backups first.
Why MantisBT upgrades fail on shared hosting
Most broken upgrades on managed shared hosting trace back to three causes, none of which require server access to avoid. The first is an in-place overwrite: uploading a new tarball on top of an old install leaves orphaned files from removed features, which produces fatal errors or subtle plugin breakage. The second is a PHP version mismatch. MantisBT 2.28.x targets PHP 8.x and the project recommends running a fully supported release such as PHP 8.4, while the upcoming 2.29.0 will raise the minimum to PHP 8.1. If your account is still pinned to PHP 7.4, the pre-install check will flag it. The third is an interrupted database migration — a PHP timeout partway through admin/install.php can leave the schema half-updated, which is exactly the scenario a verified backup exists to recover from.
Before touching anything, confirm your current state. Log into MantisBT as an administrator and open Manage → Manage Configuration, then note the version shown in the footer of the overview page. Open config/config_inc.php in File Manager and record your database name, user, host, and table prefix. In cPanel this file sits under /home/USER/public_html/mantis/config/config_inc.php (adjust for your document root); in DirectAdmin the equivalent path is /home/USER/domains/example.com/public_html/mantis/config/. Knowing the exact database credentials and file paths removes guesswork later.
Set your PHP version first so the migration runs on the target runtime. In cPanel Jupiter, open MultiPHP Manager, select the domain, and set it to PHP 8.3 or PHP 8.4. In DirectAdmin Evolution, use Select PHP Version (the CloudLinux PHP Selector) and pick a supported 8.x branch, then confirm the required extensions are enabled: mysqli, mbstring, gd, curl, and zip. Raise execution limits for your account with a .user.ini file in the document root so the schema migration does not time out:
; .user.ini in the MantisBT document root
max_execution_time = 300
memory_limit = 256M
post_max_size = 32M
upload_max_filesize = 32MChanges to .user.ini are cached; wait a few minutes or recycle the PHP app via the control panel before relying on the new values.
Full backup: database and files
A safe upgrade starts with two backups taken at the same point in time: the MySQL database and the complete MantisBT directory, including any file-system attachment store. Take the database backup through phpMyAdmin (reachable from both cPanel and DirectAdmin). Select your MantisBT database in the left panel, open the Export tab, choose the Custom method, set the format to SQL, and enable Add DROP TABLE / VIEW / PROCEDURE so the dump can cleanly restore over a damaged schema. For databases with many issues and attachments stored in the mantis_bug_file_table, tick gzipped compression to keep the file inside upload limits. Save the resulting .sql.gz with a dated filename such as mantis-db-2026-10-15.sql.gz.
For the files, use File Manager. Navigate up one level from the MantisBT folder, select the mantis directory, and use Compress to create mantis-pre-upgrade.tar.gz. This single archive is your complete rollback image of the current code, configuration, and any attachments stored under uploads/ or a path set in $g_absolute_path_attachment_default. Download both backups off the server so a disk event cannot take your working copy and your safety net at once.
If your plan includes JetBackup or the native cPanel/DirectAdmin backup wizard, generate a full account snapshot as well, but do not treat it as a substitute for the targeted database and directory backups — restoring a single application from a whole-account archive is slower and riskier than swapping a folder you control directly.
Build a staging copy and run the upgrade there first
Rather than upgrading production directly, build a disposable staging copy in the same account. The isolation keeps users out of a half-migrated system and gives you a true dry run of the schema changes against a copy of real data.
In phpMyAdmin, create a second database and user through cPanel's MySQL Databases or DirectAdmin's MySQL Management, then import your .sql.gz dump into it. In File Manager, create a subdirectory such as public_html/mantis-staging/ and extract the official 2.28.4 tarball into it. Download the release from the project's site or GitHub and, where a SHA-256 digest is published, verify the archive checksum before extracting — File Manager's extract tool handles the .tar.gz directly. Copy your old config/config_inc.php into the staging config/ folder and edit the database settings to point at the staging database and user. Also copy any custom/ content, custom strings, and third-party plugin folders from plugins/.
Protect the admin tooling during the run. MantisBT serves the migration from mantis-staging/admin/install.php; browse to it, review the pre-installation checks (PHP version, extensions, database connectivity), and run Install/Upgrade Database. Watch for any step that stalls, and check your account's error_log in File Manager if a page returns a 500. Once staging reports the new version in the footer and a few issues, notes, and attachments render correctly, you have validated the exact migration production will perform.
Production cutover and rollback
With staging proven, the production cutover is a short, deterministic sequence. Put MantisBT into read-only mode first by creating a file named mantis_offline.php in the document root — its presence disables access for everyone except administrators and prevents new writes mid-migration. Take one final fresh database dump so the production data matches the moment of cutover.
Extract the same verified 2.28.4 tarball into a new directory, for example public_html/mantis-new/, then copy the production config/config_inc.php, the plugins/ folder, custom files, and any local attachment directory into it. Do not reuse the staging config, since it points at the staging database. Now swap the directories with File Manager's rename tool: rename the live mantis to mantis-old, then rename mantis-new to mantis. Browse to mantis/admin/install.php and run the database upgrade against the production database. When it completes, delete mantis_offline.php, hard-refresh the overview page, and confirm the footer shows 2.28.4. Finish by removing admin/install.php access — delete the admin/ directory from the live tree, since it is only needed during upgrades and is a frequent target otherwise.
Rollback is the inverse and is why the rename approach matters: if the migration errors out or the site misbehaves, rename mantis back to mantis-failed, rename mantis-old back to mantis, and restore the pre-cutover database dump through phpMyAdmin (the DROP TABLE statements in your custom export make this a clean overwrite). Because the old code and the matching database snapshot were captured together, the restore returns you to a consistent working state in minutes rather than a reconstruction effort. For readers managing several PHP applications with overlapping worker and cron constraints on one plan, our guide to Kanboard scaling on shared hosting covers related resource tuning that applies to busy trackers too.
Keep mantis-old and the dated backups on the account for a week of real use before deleting them. Only after confirming attachments, email notifications, and plugin behavior under live traffic should you reclaim the space.