Chevereto looks lightweight because it serves images, but the PHP work behind every upload is heavier than a typical blog. Each uploaded file triggers EXIF parsing, resize operations through GD or Imagick, duplicate detection, thumbnail and medium generation, and several database writes. When a gallery grows past a few hundred thousand images, or when an embedded gallery suddenly gets traffic from a forum or social share, the account starts hitting ceilings that feel random. The symptom is almost always the same (slow loads, HTTP 500, or uploads that die halfway) while the actual cause differs completely. The job before touching your plan is to identify which single resource is saturated.
Reading the signals: which resource is actually saturated
On CloudLinux shared hosting every account runs inside an LVE (Lightweight Virtual Environment) with hard caps on CPU, physical memory, entry processes, I/O, and inodes. The fastest way to see which cap you are hitting is the resource usage panel. In cPanel Jupiter open Tools > Metrics > Resource Usage, and in DirectAdmin Evolution open Advanced Features > Statistics / Resource Usage. Look at the "faults" or "limit reached" column rather than the averages, because a gallery that is fine 95% of the time but gets killed during peak minutes is a faults problem, not an average problem.
Each fault type maps to a distinct Chevereto behaviour. CPU faults (cpu) appear when many visitors request un-cached thumbnails at once or when a bulk import is running image resizing. Physical memory faults (pmem) show up during single large uploads because Imagick loads the full image into RAM to resize it. Entry process (ep) and process number (nproc) faults mean too many PHP requests are alive simultaneously, which strangles everything else. I/O and IOPS faults point at disk thrashing, usually from writing many thumbnail files or from a large MySQL table doing full scans. Inode limits are a slow-building Chevereto-specific trap that never shows as a fault but as failed writes.
Before changing anything, reproduce the failure and read your own log. Chevereto writes PHP errors to the account error log, visible in cPanel under Metrics > Errors or directly as error_log files inside public_html and the Chevereto app/ directory via File Manager. A line containing Allowed memory size of ... bytes exhausted is a pmem problem. Maximum execution time exceeded during an upload is CPU or I/O on the resize step. disk quota exceeded or No space left on device when free space clearly exists is almost always inodes. Matching the log line to the fault column removes guesswork.
The inode and I/O bottleneck most Chevereto owners miss
Chevereto stores each image as the original plus derived sizes (thumb, medium, sometimes a second thumbnail). A library of 200,000 images can consume 600,000 to 800,000 files before counting the application itself. Shared plans commonly cap inodes between 250,000 and 600,000, so a growing gallery silently approaches the limit until new uploads fail even though the GB quota is nowhere near full. Check your current count in cPanel under Statistics (the "File Usage" / inode figure) or DirectAdmin's account usage panel. If you are within 10% of the cap, no PHP tuning will help; the file count itself is the wall.
Three things live inside your account and reduce inode and I/O pressure without needing a bigger plan. First, move storage to an external S3-compatible bucket. In the Chevereto dashboard go to Dashboard > Settings > External Storage, add an S3 or Backblaze B2 provider, and set it as the active storage. New images then write to object storage and stop consuming local inodes entirely. Second, prune orphaned and expired content under Dashboard > Settings > Image Upload by enabling guest image expiration and running the cron-driven cleanup. Third, reduce how many derivatives Chevereto generates by disabling the medium size if your theme never requests it, which cuts file creation roughly by a third.
For raw I/O during resizing, Imagick and GD both write temporary files. Point PHP's temp directory to a location inside your account and keep it clean by setting an explicit path in .user.ini:
; place in public_html/.user.ini
upload_tmp_dir = "/home/youruser/tmp"
sys_temp_dir = "/home/youruser/tmp"This keeps temp writes on your allocation rather than a shared location that may throttle, and makes stalled uploads visible so you can delete leftover temp files that otherwise bloat inode counts.
Tuning PHP memory, execution time, and workers from your account
Most upload failures reported as "broken" are a PHP memory or time limit that is set too low for the image dimensions being processed. A 24-megapixel JPEG decompressed in memory can need 250–400 MB during resize even though the file on disk is 6 MB. The levers are yours to set through the PHP Selector or .user.ini; you never touch php.ini or server config. In cPanel open Software > Select PHP Version > Options, or in DirectAdmin PHP Selector > Options, and raise the values. The equivalent .user.ini in public_html looks like this:
memory_limit = 512M
max_execution_time = 120
max_input_time = 120
post_max_size = 64M
upload_max_filesize = 64M
max_file_uploads = 20Keep post_max_size larger than upload_max_filesize, and set memory_limit generously because Chevereto's resize step is the heaviest single moment. After saving, confirm the change took effect in Chevereto under Dashboard > Server, which echoes the live PHP limits. If the dashboard still shows old values, your host enforces limits per-domain and you should set them in the PHP Selector UI instead of the file.
Worker exhaustion is more subtle. Your plan allows a fixed number of concurrent PHP entry processes, often 20 to 40. A viral embedded gallery can open dozens of simultaneous requests for images that have not been cached yet, each one tying up a worker while it resizes. The fix is to stop PHP from handling image delivery at all. Let LiteSpeed serve finished files directly and set long cache headers on the image directory with an .htaccess file inside Chevereto's images/ folder:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
</IfModule>
<IfModule mod_headers.c>
Header set Cache-Control "public, max-age=31536000, immutable"
</IfModule>With derivatives cached by browsers and the CDN edge, repeat traffic never reaches a PHP worker, and the entry-process faults disappear. This is the single most effective change for traffic-spike failures that otherwise look like "the plan is too small."
Database limits and the honest upgrade decision
Chevereto's database grows with image metadata, albums, and user activity. On shared hosting the two realistic database bottlenecks are slow queries from missing indexes on large tables and the per-user MySQL connection cap. Open phpMyAdmin from cPanel or DirectAdmin, select the Chevereto database, and inspect chv_images and chv_storages sizes under the Structure tab. If listing pages are slow, run EXPLAIN on the query from the slow-page load; a full table scan over hundreds of thousands of rows is the usual culprit. You can add a secondary index through the phpMyAdmin Structure > Index interface without any server access, which often turns a two-second gallery query into milliseconds. Avoid any global tuning; you cannot and should not touch my.cnf or run SET GLOBAL.
If connection errors appear under load ("Too many connections" or Chevereto showing a database error on peak traffic), that is a per-account ceiling you cannot raise from the UI, and it is one of the clearest signals that the workload has genuinely outgrown shared hosting. Similarly, if inode usage is capped and external S3 storage is already in use for images, or if CPU faults persist after caching and worker offloading because of constant bulk imports, you have exhausted the account-level fixes. At that point a Cloud VPS gives you dedicated CPU, controllable PHP-FPM pool sizing, a MySQL instance you can tune, and an inode allowance that scales with real disk. The upgrade is justified when the faults you see map to hard platform caps rather than to settings you still control. Work through memory, caching, inode offloading, and indexing first; if the resource usage panel still shows sustained ceiling hits after all of them, the move is no longer premature.