Tech projects

The Spark - Why I'm Building a Raspberry Pi 5 Cluster for AI & Blogging

You know how it starts? A simple thought that doesn't go away. So I started a Claude Project, and issued a prompt: could I actually build a tiny, personal data center on my desk using just a few Raspberry Pi 5s?

Jon DePalma

04 Nov 2025 — 3 min read

Table of Contents

My main goal was pretty ambitious: I wanted to make a mini-cloud. Think of it as replicating basic services like AWS EC2, DynamoDB, and Lambda, but with open-source tools instead. This way, I could host my own Python and Node.js apps, run a few small websites, and set up a proper sandbox where I could genuinely collaborate with AI models like Claude and Gemini.

Look, I’m not new to tech—I’ve spent 15+ years creating enterprise systems. But I’m really a business architect at heart, and I wanted to test something cool. Could I guide an AI to design and document the entire system, and then use its documentation to build it myself? Could I finally move past arguing with AIs about how my wife isn't in the boat and get them to design a production-ready infrastructure instead?

Gemini AI Image Fail — "Get in the boat!" **I regret how many attempts I made with this same result.** **The fix: Start a new chat with a fresh, refined prompt.**

The Runaway Train

As soon as Claude started sketching things out, the project immediately became a Runaway Train.

My simple idea quickly turned into this massive, complicated architecture. Claude’s first design had at least 15 separate services — complex logging, multiple specialized databases—suggesting it would take me a solid six weeks just to implement the thing. The first diagram was certainly impressive, but honestly, it was overwhelming. It was way too much for a simple personal home lab.

Initial Architecture Diagram — Claude's first architecture diagram **Note: I asked Claude to create a Draw.io compatible XML file for this image.**

That was the first big lesson: Context is king! When you’re designing with AI, you’ve got to be ready to grab the emergency brake. Without scope and context, AI can drift into the most comprehensive, enterprise-level solution possible, even if you just need a small sandbox to play in.

The LLM Detour

Just as I was trying to figure out how to pull back on the scope, I took a side trip to see what Gemini thought of my plan.

I gave Gemini a similar request, and bam! It suggested a totally different path: Use Proxmox, a virtualization platform, to manage the operating systems on the Pis. That sounded awesome in theory—ultimate flexibility and control!—the dream home lab solution.

But, a quick check by me (the human-in-the-loop!) revealed the catch: Proxmox, right now, doesn't actually work on Raspberry Pi's ARM architecture. I went straight back to Claude, asked about the Proxmox idea, and Claude instantly confirmed the incompatibility.

This little "LLM-vs-LLM" moment was a turning point. It emphasized human judgment is irreplaceable. AI is an incredible partner, but you still need an informed driver to steer around context, hardware limits and platform realities.

In this journey, I have also found uses for both Gemini (my creative partner) and Claude (my technical partner). The lessons continue to pile up even before the hardware has shipped!

Keep It Simple, Stupid

After that detour and seeing how complicated Claude’s first draft was, I knew one thing: it was time to simplify the vision.

The path to the Simplified Implementation Plan became crystal clear. I needed to ditch the bloat and focus on the absolute core mission:

Public Website: Just getting a Ghost blog successfully launched.
App Hosting: Setting up a core K3s (Kubernetes) cluster to build and host my customer apps.
Storage: Leaning on my existing NAS for persistent storage instead of over-engineering a new solution just for the cluster.

This new context drastically cut the timeline, reduced the initial cost, and gave me a clear, simple path forward. Now I am starting with a three-device cluster, and have already documented a strategy for scaling up or migrating to the cloud later if the project actually takes off.