PunBB was built around a minimal core, which shapes every conversation about media. Unlike a full-featured forum, PunBB ships with only avatar handling in its base install; image attachments, gallery features, and thumbnail generation come from third-party extensions such as the classic Attachment extension or PunBB Attach mods. That design keeps the codebase fast, but it also means storage pressure on a shared account rarely comes from PunBB itself. It comes from the folders those extensions write into, from oversized avatars users upload, and from static assets (CSS, JS, forum logos, smilies) being re-fetched on every page view because nothing tells the browser to cache them.

On Managed Cloud Shared Hosting you are an unprivileged user, so the goal is to work entirely within your home directory and control panel. You cannot change server-wide image libraries or PHP settings in my.cnf or /etc/. What you can do is control which PHP version and extensions PunBB runs under, set per-account upload limits through .user.ini, cap avatar and attachment sizes inside the PunBB admin, and use .htaccess to add caching and hand static delivery to a CDN. Those levers, applied together, keep your disk quota and inode count healthy while making image-heavy topics load quickly.

Controlling avatars and upload sizes at the source

Avatars are the one media type PunBB manages natively, and they are also the most common cause of quota creep because every registered account can hold one. In the AdminCP, open Admin → Settings → Features. There you will find the avatar controls: enable or disable uploaded avatars, set the maximum width and height in pixels, and set the maximum file size in kilobytes. Sensible values for a shared account are 100×100 pixels and roughly 20–30 KB. PunBB stores uploaded avatars in the img/avatars/ directory under your forum root (for example /home/USER/public_html/img/avatars/), named by user ID. Because it does not resample every existing avatar when you tighten limits, the new caps only apply to future uploads, so it is worth auditing that folder in the cPanel File Manager or DirectAdmin File Manager to spot old, oversized files.

PunBB checks the GD extension to validate and constrain avatar dimensions. If avatar uploads fail or dimensions are not enforced, confirm GD is active for your PHP version. In cPanel go to Software → Select PHP Version (the MultiPHP / PHP Selector interface); in DirectAdmin open Extra Features → Select PHP Version. Tick the gd extension checkbox and save. While you are there, pick a modern PHP branch that your PunBB version supports—newer PHP handles image functions faster and with less memory.

Upload size has two ceilings. The first is PunBB's own KB limit above. The second is PHP's upload_max_filesize and post_max_size. Because you cannot edit the global PHP configuration, place a .user.ini file in your forum root to raise or lower the account-level values:

; /home/USER/public_html/.user.ini
upload_max_filesize = 4M
post_max_size = 6M
memory_limit = 128M
max_execution_time = 60

Keep these conservative. Large values invite users to upload full-resolution phone photos, which is exactly the storage problem you are trying to avoid. Changes to .user.ini are picked up after the configured refresh window (commonly 300 seconds) rather than instantly, so wait a few minutes before testing.

Attachment extensions, thumbnail folders, and quota discipline

If your board allows image attachments, that capability comes from an extension rather than the PunBB core, so the exact settings live in Admin → Extensions once the extension is installed and enabled. Most attachment extensions expose a configuration page where you set allowed file extensions, a per-file size cap, a per-post limit, and whether thumbnails are generated. Restrict allowed extensions to what you genuinely need—jpg, jpeg, png, gif, and optionally webp—and reject archive or executable types outright. That single change prevents your account from becoming a general file dump.

Attachment extensions write to a dedicated directory, frequently img/attach/ or a folder you specify during setup. Thumbnails, when enabled, are stored alongside originals or in a thumbs/ subfolder. Because these are physical files, they consume both disk space and inodes, and inode limits on shared hosting are easy to hit when thousands of small thumbnails accumulate. Enable thumbnail generation only if your extension caches thumbnails to disk (so they are created once, not on every request), and periodically review the folder size. In cPanel the File Manager shows folder sizes, and the Metrics → Disk Usage / Inode tools reveal which directories dominate your quota. In DirectAdmin, check System Info & Files → Disk Usage.

Confirm the attachment and thumbnail directories are writable by your PHP process (typically 0755 for folders, set through the File Manager's Permissions dialog) but never 0777. If an extension supports WebP output, it will only work when the GD build for your selected PHP version includes WebP support, which most current PHP branches on CloudLinux do. Test by uploading a WebP file after enabling the extension; if it is rejected, the extension likely predates WebP handling and you should keep to JPEG and PNG rather than patch core files.

Browser caching and CDN offload for static media

Even a well-pruned board re-serves the same logo, stylesheet, smilies, and avatars on every page load unless you tell browsers to cache them. Since PunBB's static assets live under predictable paths (/img/, /style/, and the avatar folder), an .htaccess file in your forum root can set long cache lifetimes. LiteSpeed honors standard mod_expires and mod_headers directives, so this works without any server-level change:

# /home/USER/public_html/.htaccess
<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 text/css "access plus 1 week"
  ExpiresByType application/javascript "access plus 1 week"
</IfModule>

<IfModule mod_headers.c>
  <FilesMatch "\.(jpg|jpeg|png|gif|webp|css|js)$">
    Header set Cache-Control "public, max-age=2592000"
  </FilesMatch>
</IfModule>

Serve these files compressed as well, which helps CSS and JS more than already-compressed images:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/css application/javascript text/html
</IfModule>

For boards with a broad audience, a pull-zone CDN removes repeat image traffic from your hosting bandwidth entirely. The account-friendly approach is a reverse-proxy CDN such as Cloudflare, activated at the DNS level for your domain—no code change to PunBB is required, and the caching headers above tell the CDN how long to hold each asset. If you prefer to serve only static media from a CDN subdomain (for example cdn.example.com mapped to your /img/ folder), you can rewrite asset references in your active PunBB style templates under style/, but keep those edits minimal and documented so upgrades do not silently overwrite them.

Because avatars and attachments are user-generated and can change, give them a shorter CDN or browser TTL than fixed theme assets, or rely on PunBB's filename-by-ID scheme plus a query string when you replace an image. The combination of tight upload caps at the source, disciplined attachment folders, long cache headers for stable assets, and a CDN for repeat delivery keeps a PunBB board fast and well within shared-hosting quotas without ever needing root access. If you also want to speed up the PHP layer that renders these pages, review your OPcache and LiteSpeed cache options alongside these media steps: Phorum Performance & Caching on Shared Hosting covers the same LiteSpeed and OPcache principles that apply to PunBB.