HumHub stores every profile picture, space banner, post attachment, and inline image under the uploads/ directory of its web root, while generating resized derivatives on demand through PHP's image libraries. On a Managed Cloud Shared Hosting account running LiteSpeed on CloudLinux, the part of this pipeline you can actually influence is the PHP runtime, the application's own file settings, and how the web server caches and serves the resulting static files. You do not control the ImageMagick binary installation or server-wide PHP defaults, so the work centers on choosing the right PHP extension in the selector, raising per-account upload limits through .user.ini, and setting sensible quality and size values inside the HumHub admin dashboard.

Getting this right matters because a community site accumulates media quickly. Oversized originals eat into your disk quota, poorly compressed thumbnails waste bandwidth on every page load, and a mismatch between PHP limits and the application's declared maximum produces confusing upload failures. The sections below walk through the image engine, the upload size chain, thumbnail and storage housekeeping, and finally offloading static media to a CDN using rules you are permitted to place in .htaccess.

Choosing the image engine: GD versus Imagick in PHP Selector

HumHub renders thumbnails and profile images through the Imagine library, which can drive either the GD extension or the Imagick (ImageMagick) PHP extension. GD is almost always present and handles JPEG, PNG, and GIF adequately, but Imagick produces noticeably sharper downscaled thumbnails, preserves color profiles better, and handles transparency more reliably. Older HumHub releases exposed an ImageMagick convert command path under Administration → Settings → Advanced → Files, but that option was removed in version 1.5, and the application now expects the Imagick or GraphicsMagick PHP extension to be loaded instead of shelling out to a binary.

On cPanel Jupiter, open Select PHP Version (the PHP Selector), switch to the Extensions tab, and confirm that imagick is checked. On DirectAdmin Evolution the same control lives under PHP Selector → Extensions. If imagick is available on your plan, enabling it lets HumHub automatically prefer it. Verify the result by creating a small file in your web root, for example phpcheck.php containing <?php phpinfo();, loading it in the browser, and searching the page for an imagick section. Delete that file immediately afterward so it is not left exposed.

If only GD is offered on your account, HumHub still works; you simply rely on GD's output. In that case, avoid uploading enormous originals, because GD holds the full decoded bitmap in memory while resizing. A 6000×4000 pixel photo can require well over 100 MB of RAM to process, which can collide with your PHP memory_limit. Keep the memory ceiling reasonable in your .user.ini (for example memory_limit = 256M) rather than pushing it to extremes that your plan may not honor.

Aligning the upload size chain: PHP limits and HumHub's file setting

Upload failures in HumHub are usually a disagreement between three independent limits, and the smallest one wins silently. The first two are PHP directives, upload_max_filesize and post_max_size; the third is the application's own Maximum upload file size under Administration → Settings → Advanced → Files, expressed in megabytes. A long-standing source of confusion is that raising the HumHub value above the PHP ceiling does nothing, and files that exceed the PHP limit may produce only a vague "an unknown error occurred" message rather than a clear size warning.

Set the PHP directives through a .user.ini file in your HumHub document root (for LiteSpeed and PHP running as a per-user process this is the supported per-account method; do not attempt to edit any file under /etc):

; .user.ini in the HumHub web root
upload_max_filesize = 32M
post_max_size = 40M
max_execution_time = 120
memory_limit = 256M
max_input_time = 120

Keep post_max_size a step larger than upload_max_filesize so that form fields and the file body together still fit. LiteSpeed reads .user.ini on a short interval, so allow up to five minutes, or bump the mtime of the file by re-saving it in File Manager, before testing. Once PHP is set, open the HumHub admin dashboard and set Maximum upload file size to a value at or below upload_max_filesize — for instance 30 MB when PHP allows 32 MB. This keeps HumHub returning a friendly, specific size error instead of letting the request die at the PHP layer.

If uploads still cap out at roughly 1 MB despite correct values, confirm you edited the .user.ini in the same directory HumHub actually serves from (the folder containing index.php), not the account home directory. You can confirm the effective values with the same temporary phpinfo() page described earlier, checking the Local Value column rather than the master value.

Controlling thumbnail quality and reclaiming upload storage

HumHub generates several derivatives for each image: a squared profile crop capped at 800 px wide for the original, inline preview thumbnails for attachments, and space/banner images. These derivatives live alongside the originals in uploads/file/ and the profile image folders, and they are what browsers actually download on a busy stream. Two levers under your control reduce their weight.

First, encourage members to post reasonably sized images rather than full camera originals. If your plan offers the marketplace Image Crop module, installing it through Administration → Modules lets you force a crop and aspect ratio on uploads, which trims stored dimensions at the source. Modules are installed entirely through the AdminCP marketplace, so no filesystem or Composer access is needed on a shared account. Second, prefer the Imagick engine from the first section, because its downscaled JPEGs reach the same visual quality at a smaller byte count than GD output, directly lowering per-page transfer.

For storage housekeeping, use the cPanel or DirectAdmin File Manager to inspect disk usage under the HumHub uploads/ tree, and the Disk Usage tool to see which directories dominate your quota. When members and content are deleted inside HumHub, the application removes the associated files, but orphaned derivatives can accumulate over years of use. Rather than deleting files manually — which risks breaking valid references — run the built-in maintenance from Administration → Information → Logging and the file module's cleanup routines, and keep database and file state consistent. If you need to audit which records point at which files, phpMyAdmin exposes the file table, where each row maps a stored file to its owning content; never run bulk DELETE statements there unless you have a verified backup, because file rows and physical files must stay in sync.

Modern formats like WebP and AVIF can shrink images dramatically, but HumHub's core pipeline does not transcode user uploads to those formats, and GD/Imagick availability for AVIF depends entirely on how your account's PHP was compiled. Do not assume AVIF support; treat WebP/AVIF delivery as a CDN-side optimization, covered next, rather than something you force inside the CMS.

Caching and offloading static media with LiteSpeed and a CDN

Even perfectly sized thumbnails benefit from aggressive browser caching and edge delivery. Because HumHub serves attachments through PHP controller actions for permission checks, you cannot blindly cache every media URL, but genuinely public static assets — theme images, the logo, icons, and files under publicly readable asset paths — are safe to cache hard. Add far-future cache headers for static types in an .htaccess file in your web root, which LiteSpeed honors natively:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpeg "access plus 1 month"
  ExpiresByType image/png  "access plus 1 month"
  ExpiresByType image/gif  "access plus 1 month"
  ExpiresByType image/webp "access plus 1 month"
  ExpiresByType image/svg+xml "access plus 1 month"
  ExpiresByType text/css   "access plus 1 week"
  ExpiresByType application/javascript "access plus 1 week"
</IfModule>
<IfModule mod_headers.c>
  <FilesMatch "\.(jpg|jpeg|png|gif|webp|svg|css|js)$">
    Header set Cache-Control "public, max-age=2592000"
  </FilesMatch>
</IfModule>

For edge delivery, a pull-zone CDN such as Cloudflare or BunnyCDN is the most practical route on shared hosting, since it needs no changes to how HumHub writes files. You keep the origin unchanged and let the CDN fetch and cache static responses based on the headers above. Several CDNs can also perform on-the-fly WebP or AVIF conversion and responsive resizing at the edge, which is where format modernization realistically belongs for a shared-hosting HumHub, because the origin PHP is not transcoding uploads itself.

Two cautions apply. Do not route permission-protected attachment URLs through a public CDN cache, or private content could be served to users who should not see it; restrict CDN caching to clearly public asset paths and let HumHub's PHP handle the gated downloads. And if you later set an external base URL for assets, configure it inside HumHub's own settings and configuration rather than rewriting internal paths by hand, so that generated links stay consistent. The same careful separation of static versus dynamic requests that improves media delivery here also underpins broader performance work, much like the layered caching approach described for other PHP apps in Statamic performance and caching on shared hosting.

With the right PHP extension selected, upload limits aligned across all three layers, thumbnails kept lean, and public static media cached and offloaded to the edge, a HumHub community runs comfortably within a shared-hosting quota while serving images quickly to every member.