AI Roundtable Open Debate · 4 models
absolute optimal way to aggregate and provide a frontend for 20+TBs of manga/manhwa/manhua to many users with the cheapest possible setup
Answer: Self-host on used enterprise hardware using Cloudflare Tunnels and aggressive edge caching to eliminate recurring cloud storage fees. (All 4 models agreed)
Model Responses
Grok 4.20 (changed mind)
Answer: The cheapest optimal setup is self-hosting Kavita or Komga on low-power or used consumer/enterprise hardware with bulk HDDs in JBOD, using Cloudflare Tunnel and aggressive CDN caching for static images to support many users without high recurring costs.
After reviewing the other models, I adjusted my position to more strongly incorporate Cloudflare's free CDN caching for static manga images, as this is crucial for scaling to many users without saturating home upload bandwidth. My original emphasis on low-power mini PCs or Raspberry Pi with WireGuard/Cloudflare Tunnel was close but underplayed the caching rules for long TTLs on immutable image assets, which can achieve 95% cache hits and offload delivery to Cloudflare's edge network. Claude Opus 4's detailed breakdown on using mergerfs for drive pooling, converting to WebP/AVIF for 30-50% size reduction, and configuring Cloudflare Page Rules convinced me to refine the approach for better performance and efficiency at this scale. Their cost estimates (under $500 initial for used hardware and drives, ~$10-20 monthly electricity) align with cheapest principles while addressing thumbnail generation slowdowns on ultra-low-power devices like a Pi for 20TB libraries. GPT-5.4's cloud object storage and static frontend suggestion was not compelling, as Backblaze B2 or similar would cost $100+ monthly for 20TB storage alone, plus potential egress fees, far exceeding self-hosted power costs. Gemini's take was similar to Claude's but added little new nuance. Self-hosting remains superior for absolute minimal ongoing expense, with one-time hardware under $1000, free open-source tools for metadata and frontend, and Docker for easy setup on Linux. This keeps everything under personal control, supports Tachiyomi and web readers, and scales by adding drives. Legality assumed for personal or authorized use only, with VPN/tunnel for security instead of public ports.
GPT-5.4 (changed mind)
Answer: I would narrow my answer but not fundamentally change it: the cheapest scalable setup is self-hosted bulk storage running manga-server software, with Cloudflare or another CDN caching static images in front—rather than fully cloud-hosted object storage as the primary origin.
The other models did change my emphasis, but not my underlying architecture logic. My original answer correctly identified the main economic truth: at 20+ TB, storage, bandwidth, and cache-hit rate dominate costs, and static image delivery with aggressive edge caching is the right serving model. That part still stands. What the other answers did better was force a distinction between "cheapest in total recurring cost" and "cheapest practical internet-scale cloud architecture." For this specific prompt, the user asked for the cheapest possible setup, and Grok, Claude, and Gemini were right that a self-hosted origin on cheap used HDDs is usually materially cheaper than paying ongoing cloud object-storage fees for 20+ TB. In other words, if the priority is minimizing recurring spend above all else, buying disks once and serving from home or a colocated cheap box can beat B2/R2/S3-style storage economics. Claude Opus 4 made the strongest case because it combined the two perspectives instead of treating them as opposites. Its argument effectively said: use ultra-cheap self-hosted storage as the origin, but still rely on CDN behavior for the actual scaling path. That is closer to the true optimum for this exact question than a purely cloud-origin design. Gemini made the same core point clearly as well: local storage plus Cloudflare caching is what turns a cheap home origin into something that can serve many users. I do not fully endorse the strongest versions of their claims, though. The idea that Cloudflare's free tier can simply be treated as a guaranteed no-cost CDN for a massive copyrighted image library serving many users is operationally and policy-wise shaky. Cache behavior, terms-of-service issues, hot-object eviction, origin pulls, abuse handling, and sustained high-volume media delivery are all real constraints. So while their architecture is directionally right for cost minimization, some of the wording around "effectively unlimited free CDN" was too optimistic. Grok's answer was less compelling because it focused mostly on self-hosting software and consumer hardware, which is useful, but it underplayed the delivery-layer problem. For "many users," the bottleneck is not just storing 20+ TB cheaply; it is serving it repeatedly without crushing the origin's upload bandwidth. A plain Komga/Kavita-on-a-mini-PC answer is incomplete unless paired with aggressive caching or another distribution layer. So my position changes only in emphasis: the absolute cheapest practical setup is not cloud object storage first. It is a self-hosted low-cost storage origin using something like Kavita or Komga for aggregation and frontend, fronted by a CDN/cache layer for static page assets, with image conversion, long TTLs, and minimal dynamic infrastructure. That preserves my original bandwidth/cache reasoning while adopting the other models' stronger point that, for 20+ TB, owning the disks is usually cheaper than renting the storage. Because this is a refinement rather than a total reversal, the main influence was Claude Opus 4, with Gemini 3.1 Pro reinforcing the same conclusion. Claude's answer most convincingly integrated storage economics, reader software, and delivery architecture into one coherent cheapest-possible setup.
Claude Opus 4
Answer: The optimal setup is a self-hosted Kavita or Komga server running on cheap used hardware with high-density used HDDs in a mergerfs pool, served behind Cloudflare's free CDN with aggressive caching via Cloudflare Tunnel, and accessed through the built-in web reader or Tachiyomi/Mihon-compatible clients.
I'm maintaining my original position with minor refinements, as the other models largely converged on the same core architecture rather than presenting fundamentally different approaches. **Why the other arguments didn't change my mind:** Grok's answer essentially agreed with mine but was less detailed. The suggestion of a Raspberry Pi 5 with USB 3 enclosures is actually problematic for 20+ TB serving to many users—the Pi's I/O throughput and CPU would bottleneck under concurrent image serving, and USB enclosure reliability at scale is poor. A used enterprise server or even a basic desktop with an HBA card is far more practical. Grok's WireGuard VPN suggestion is also impractical for "many users"—you can't expect casual readers to configure VPN clients. GPT-5.4's cloud-native approach (object storage + CDN + serverless) is architecturally elegant but fails the "cheapest possible" requirement for this specific use case. Even the cheapest object storage at 20+ TB runs $100+/month in perpetuity. Egress fees compound this further unless cache hit rates are extremely high from day one. The suggestion of pre-generating static sites, search indexes, and image derivatives adds significant pipeline complexity. The legal caveat is fair but irrelevant to the technical question. The argument that "one machine is fragile" is true, but for a manga library where content can be re-obtained, the risk tolerance is very different from a business-critical system. Total cost of ownership for self-hosting is dramatically lower here. Gemini's answer was closest to mine and reinforced my position rather than challenging it. The WebP conversion suggestion is a genuinely useful addition I should have mentioned—converting to WebP can save 20-30% storage and dramatically improve page load times. The emphasis on Cloudflare's edge caching handling 95%+ of traffic is exactly right and is the key insight that makes self-hosting viable for many users. **My refined position remains self-hosting because:** 1. **Storage cost**: Used HDDs at $10-15/TB is a one-time cost of ~$200-300 for 20TB. Cloud storage would cost that every 2-3 months, forever. 2. **Bandwidth**: Cloudflare Tunnel + free CDN caching eliminates the home upload bottleneck for static image content. Popular series get cached at edge nodes globally. 3. **Software**: Kavita/Komga are purpose-built for this exact use case, are free, and provide user management, reading progress tracking, metadata scraping, and responsive web readers out of the box. 4. **Scaling**: The CDN does the heavy lifting for concurrent users. Your origin server only needs to handle cache misses, which for a manga library with Zipf-distributed popularity, will be a small fraction of total requests. The only meaningful addition from other models was Gemini's WebP conversion suggestion and GPT's point about pre-generating thumbnails/derivatives as an offline pipeline, both of which complement rather than contradict my original architecture.
Gemini 3.1 Pro
Answer: The absolute cheapest and most optimal setup remains self-hosting the 20+ TB library on low-cost, refurbished hardware using high-capacity HDDs, managed by software like Kavita, and routed through Cloudflare Tunnels for free CDN caching.
I maintain my core position because self-hosting is the only viable way to avoid crippling recurring monthly fees at a 20+ TB scale. While GPT-5.4 argues for a cloud object storage architecture, even budget providers like Backblaze B2 charge roughly $120 per month for 20TB. Over a single year, this totals over $1,400—vastly exceeding the one-time capital expenditure of a refurbished enterprise PC or mini-PC and a couple of shucked high-capacity hard drives. However, Claude Opus 4 offered excellent technical refinements that perfectly complement and strengthen this self-hosted architecture. First, using a JBOD or mergerfs configuration instead of traditional RAID maximizes usable storage space by prioritizing raw capacity over strict redundancy—an acceptable tradeoff for a media library where content can be re-downloaded if a drive fails. Second, batch-converting the raw image archive into modern WebP or AVIF formats is a phenomenal optimization. This step alone can reduce the 20+ TB storage footprint by 30-50%, drastically lowering initial hard drive costs and further accelerating web delivery. For the network and delivery layer, utilizing Cloudflare Tunnels remains the undisputed champion for cost, scalability, and security. By establishing a reverse tunnel to Cloudflare's edge, you completely hide your home IP address and avoid opening router ports. More importantly, by configuring aggressive Edge Cache TTL page rules for static image assets, Cloudflare's CDN intercepts and serves the vast majority of user traffic. This effectively turns a standard residential internet connection into a highly scalable, globally distributed delivery network for exactly zero dollars. Finally, serving the files via open-source, containerized software like Kavita or Komga provides a polished web frontend and native API support for mobile reading apps like Tachiyomi. This integrated stack delivers an enterprise-grade user experience with essentially zero ongoing costs beyond minimal local electricity.
Final Summary
The AI Roundtable unanimously concluded that renting 20TB of cloud storage is a financial trap, advocating instead for a 'buy once, host forever' local origin model. Claude Opus 4 and Gemini 3.1 Pro led the charge for used enterprise HDDs and WebP conversion to slash costs, while GPT-5.4 and Grok 4.20 ultimately agreed that Cloudflare’s free CDN is the only way to scale to many users on a budget.
All 4 models agreed