Kanboard runs comfortably on modest resources, which is exactly why performance problems on shared hosting rarely come from the application itself. They come from the way a default install is wired: a single SQLite file handling every read and write, email and automation actions firing inline with the web request, and a PHP worker pool that stalls when several board updates arrive at once. On a LiteSpeed/CloudLinux account you have real, enforced ceilings on CPU seconds, entry processes, I/O throughput, and inodes. When a Kanboard team of ten or fifteen people starts dragging cards, uploading attachments, and triggering automated actions, those ceilings are reached long before the PHP code becomes the limiting factor.

The goal here is to pinpoint which specific resource is saturating and fix it through your hosting account tools. Only after you have moved Kanboard off SQLite, offloaded its cron work, and tuned its PHP limits should a Cloud VPS enter the conversation.

Reading the real bottleneck signals

Start with evidence rather than assumptions. In cPanel Jupiter, open Metrics → Resource Usage (the CloudLinux LVE stats) and look at the last 24 hours. The three columns that matter for Kanboard are CPU, EP (entry processes, which map to concurrent PHP requests), and IO/IOPS. In DirectAdmin Evolution the same data lives under Advanced Features → Resource Usage or the CloudLinux graphs on the user dashboard. A board that feels sluggish but shows near-zero CPU and heavy IOPS faults is almost always an SQLite locking problem, not a code problem. A board that pins CPU during specific minutes of the hour is being hit by an inefficient cron job.

Next, read Kanboard's own log. The application writes to data/debug.log inside your document root (for example /home/youruser/public_html/data/debug.log) when debug mode is enabled, and PHP errors land in the per-directory error_log file that LiteSpeed creates next to index.php. Open both in cPanel File Manager. Two patterns recur: database is locked or SQLITE_BUSY messages, which confirm write contention on the SQLite file, and Maximum execution time exceeded or Allowed memory size exhausted, which point at the PHP limits applied to your account.

Finally, check inodes. Kanboard stores every uploaded attachment and every generated thumbnail as a separate file under data/files/ and data/uploads/. In cPanel the Statistics sidebar shows your current File Usage (inode count) against the plan cap. A busy board that accumulates tens of thousands of small attachments can hit an inode ceiling while using very little actual disk space, and once that cap is reached, new card attachments and even session writes fail silently.

Moving off SQLite: the single biggest win

SQLite is Kanboard's default because it needs no configuration, but it serializes writes with a file-level lock. On shared hosting that lock lives on a network or heavily shared filesystem, so every card move, comment, and subtask update waits for the previous write to release. Under real team concurrency this turns into the database is locked errors you saw in the log, visible to users as spinning saves and timeouts. Migrating to MySQL/MariaDB removes the single-writer bottleneck and lets the database engine handle concurrent connections properly.

Create the database through your panel first. In cPanel use MySQL® Databases to add a database and a user, then grant ALL PRIVILEGES. In DirectAdmin use Account Manager → MySQL Management → Create Database. Keep the generated names because the panel prefixes them with your account name. Then edit Kanboard's config.php in the document root through File Manager and point it at the new database:

<?php
define('DB_DRIVER', 'mysql');
define('DB_USERNAME', 'youruser_kanban');
define('DB_PASSWORD', 'strong-password-here');
define('DB_HOSTNAME', 'localhost');
define('DB_NAME', 'youruser_kanban');
define('DB_PORT', 3306);

For an existing board with data, do not hand-edit tables. Use Kanboard's built-in SQL dump: from the board go to Settings → Project management / Actions → Database and download the SQL backup, or export the SQLite file and import the schema into the new MySQL database through phpMyAdmin. On a fresh install, simply loading Kanboard after editing config.php builds the MySQL schema automatically. Once MySQL is active, the IOPS spikes tied to data/db.sqlite disappear from your Resource Usage graph, and concurrent saves stop blocking each other.

Offloading cron and tuning PHP workers

Kanboard performs background work — sending notification emails, running automated actions, calculating overdue tasks, and SLA checks — through a cron entry that calls cli cronjob. If that cron is missing, Kanboard tries to compensate during normal page loads, which stretches request times and consumes entry processes. Configure a proper cron so this work runs outside the web request path. In cPanel open Advanced → Cron Jobs, in DirectAdmin open Advanced Features → Cron Jobs, and add an entry that runs the PHP CLI binary against Kanboard's console:

*/15 * * * * /usr/local/bin/php /home/youruser/public_html/cli cronjob >/dev/null 2>&1

Use the PHP version that matches your MultiPHP selection; many accounts expose versioned binaries such as ea-php82. Running every fifteen minutes is enough for most teams and keeps the job well within your per-process CPU budget. Avoid a one-minute interval, because overlapping long cron runs will eat entry processes that web visitors need.

With the database and cron fixed, tune the PHP limits that control how much each request can consume. Set these in a .user.ini file in the Kanboard document root rather than hunting for a global ini you cannot touch. These values are honored by LiteSpeed's PHP handler per directory:

memory_limit = 256M
max_execution_time = 60
upload_max_filesize = 32M
post_max_size = 36M
max_input_vars = 3000
opcache.enable = 1

Confirm the active values in cPanel MultiPHP INI Editor or DirectAdmin PHP Options, and verify the PHP version in Select PHP Version (cPanel) is 8.1 or newer with the opcache, pdo_mysql, and gd extensions enabled. OPcache alone cuts CPU per request noticeably because Kanboard's PHP files stop being recompiled on every hit. Keep memory_limit at 256M rather than pushing higher; a runaway higher limit does not help Kanboard but does let a single request crowd out others under your entry-process cap.

Manage inodes at the same time. Periodically archive or delete closed projects from the Kanboard admin, and if attachments dominate your file count, enable an external object store only if your plan supports outbound S3 — otherwise prune stale uploads under data/files/ through File Manager. Keeping the inode count well below the plan cap prevents the silent write failures that look like application bugs.

What these fixes buy you, and when to scale

After moving to MySQL, scheduling the real cron, enabling OPcache, and controlling inodes, a Kanboard install handles a surprising amount of concurrent team activity on a shared plan. The honest signals that you have outgrown shared hosting are specific: sustained CPU faults in Resource Usage even with OPcache on, entry-process limits hit during normal business hours rather than brief bursts, or a MySQL database large enough that imports and backups routinely exceed the panel's time limits. Those indicate genuine capacity exhaustion, not configuration. If you reach that point, a Cloud VPS gives you dedicated CPU, higher process limits, and control over the database engine. For a broader framework on reading these same LVE signals across PHP frameworks, see our companion guide on Symfony resource limits and scaling. Until those ceilings are consistently saturated, the fixes above keep Kanboard fast on the plan you already have.