Tuning WP on Akash: Battle of the Bloat

OK, now we’ve got WordPress on Akash. Here’s the rub: this is a stateful deployment on fully headless hosting, and I’ve created a lease contract for a specific amount of compute, memory and storage data. How do I make sure my burgeoning site doesn’t get too big and bloated, and at the same time make it visually appealing?

When considering the requirements of precious disk space, there’s the complicating factor of backups: in order to run backups, I need to keep enough space for the backups to be created, after which the files will be moved off hosting. Every file that contributes to the total data size is also an additional complexity for backup restorations. So file bloat in the system expands non-linearly, and I’ve got to put methods in place right from the beginning to battle the bloat.

Content Delivery Network

In my line of work, a Content Delivery Network (CDN) is nothing new. CDN’s ideally do the following for you:

  • Offload static file storage from your core hosting
  • Provide content caching to allevaite compute resource demand
  • Provide edge locations near your audience so your page loads faster for everyone

As a fan of decentralization, I naturally want to use a resource such as Arweave, Filecoin or IPFS for static file storage, but at the moment neither my programming chops or WordPress generally is integrated to that task, so I’ve chosen to use Amazon AWS for my initial CDN solution.

On Amazon, CDN is made up of 4 products:

  1. S3 – high-availability static file storage
  2. Cloudfront – CDN-level service of files from S3
  3. IAM – account management for defining access to the S3 resources
  4. ACM – certificate management for the CDN

I’ll refer you to the plugin I’m using for further details on the configuration details, as I can’t improve on it:

The upshot here is that once implemented, you upload your media like you normally would in WordPress. The system uploads it to S3 and returns the reference link. When creating blog posts, you interact with the image library as you normally would, inserting images and resizing them as desired.

Issues Encountered

  • I have had some issues with editing image files within the media library, so you may need to execute your image edits before uploading.
  • Backup restorations: while restoring from backup, your images stored in the CDN might not show back up in your Media Library. This doesn’t break your existing posts, as the references for the images in those posts point directly to the CDN, but if you’re re-using images for future posts, you may need to rename them (so as not to break the existing CDN content links) and re-upload for later use.

Note that these issues exist with an offloaded image/CDN architecture using traditional Web2.0 hosting, so these shortcomings are not a reason to avoid the new Web3.0 solutions. To the contrary, the lean and mean requirements of Web3.0 architectures drive creative solutions to existing problems that are ignored through indolence or opulence, but are still problems.

Build Me a Better CDN

For all the crypto fans out there, I know there are file storage and CDN solutions on the way–and with all the new projects out there I may not have heard of some worthy of integration. Please let me know when I can ditch the workable but centralized AWS solution for something decentralized.

Here’s to your efforts in battling the bloat!


Add a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.