I recently built a small Ubuntu Linux server using a Raspberry Pi 5, and I had Claude along for the entire ride as my real time Linux expert and troubleshooting companion. This is the story of how that went.

Why a Raspberry Pi?

I wanted a machine I could break.

If I want to run sudo rm -rf / just to watch the meltdown, I can. I wanted a mini supercomputer I could keep in a shirt pocket.

Not a cloud instance with a monthly bill attached to every experiment. Not my personal laptop. Not some VM I'd forget was running. A physical computer sitting on my desk that I built with my own hands and could nuke without consequences.

I can try Ubuntu, then Debian, then go back. Set up Apache one day and tear it down the next. Install MySQL, PostgreSQL, Redis, or maybe all three at once. No one cares. No bill arrives. No production system goes down. No users or customers impacted.

Full command line freedom. 😄

A $250 Adafruit gift card from work (thank you!) was the final push I needed. Turns out you can build a surprisingly complete little Linux server for right around that budget, with a few cents to spare. Literally.

The Shopping List

Everything except the SD card came from Adafruit. Here's what you actually need:

Total: ~$249.21

A couple of notes: Don't cheap out on the power supply, an underpowered Pi is an unstable Pi. The Case + Fan combo handles cooling perfectly for a headless server. And grab the SD card from Amazon since Adafruit's Pi branded cards are currently out of stock.

Oh, and Adafruit threw in a couple of freebies with the order including a KB2040 microcontroller board. Because Adafruit is just like that. 😄

Assembly

The Pi 5 case comes in three pieces. Assembly is straightforward but there's one thing nobody tells you upfront: there's a small metal heatsink with a sticky thermal pad on it that goes directly onto the CPU chip before anything else. Stick that down first, then seat the board into the bottom of the case, connect the small fan cable to the two pin connector on the board, snap the middle piece down, then the lid.

The whole thing takes maybe five minutes. And when you're done you've got a complete computer the size of a Pop Tart sitting in your hand.

That moment is genuinely wild. A full Linux server. In your hand. For $250.

The last computers I built were a 486 around 1997 and a Pentium II around 99/2000. If memory serves, the process was a bit more involved. The first time I added extra RAM to the 486 I felt like I was performing surgery on a space shuttle. 😄

The Linux Question

Which Linux? This is the question that launches a thousand forum arguments. But for this project the answer was pretty straightforward: Ubuntu Server 24.04 LTS.

Here's why. Ubuntu Server is what runs on the vast majority of cloud servers in the wild, including AWS EC2. Everything you learn on it transfers directly to real world server work. It uses apt for package management, systemctl for service management, and has the largest community and documentation base of any Linux distro. When something goes wrong, and something always goes wrong, someone on the internet has already had that exact problem.

I went with LTS because Canonical backs it with security updates for five years. No chasing OS upgrades every six months.

I should mention this wasn't my first rodeo with Linux. Around 1999 I spent the better part of a year trying to get Red Hat installed on a Pentium II. I'd boot from the CD, get partway through the install, and the monitor would go completely black. Over and over. I eventually got it working exactly once. The culprit, I think, was video driver support, which in that era was an absolute nightmare to configure manually.

No YouTube. No Stack Overflow. Just a Linux for Dummies book and stubbornness.

Fast forward 25 years and I'm flashing a full Ubuntu Server onto an SD card in about five minutes on my Mac. Times have changed. 😄

The Setup from Hell (and How We Got Through It)

This is where things got interesting.

Flashing Ubuntu Server onto the SD card was easy. Raspberry Pi Imager handles it in a few minutes. Configure your hostname, username, drop in your SSH public key, done. The card goes into the Pi, power it up, and theoretically you SSH in and you're off to the races.

Theoretically.

The Pi showed up in my router's device list immediately. No IP address though. I happened to be connecting the Pi to a secondary Straight Talk cellular router I have in the house. It was doing something weird with DHCP on the wired LAN ports, which turned the "plug in and SSH" step into a genuine adventure.

We tried reflashing. We tried Raspberry Pi OS instead of Ubuntu. We tried editing WiFi config files directly on the SD card from the Mac. We tried nmap, arp, ping, every network diagnostic in the book.

Here's where having Claude as a real time Linux expert actually earned its keep. Every dead end led directly to the next thing to try. No Googling, no forum rabbit holes, no waiting. Just: here's what we see, here's what it means, here's what to try next. That back and forth troubleshooting loop is where AI assistance genuinely shines.

Eventually we got Raspberry Pi OS connected via WiFi. Then when we switched back to Ubuntu Server and reflashed one final time, the ethernet just... worked. We think plugging the ethernet cable in before powering the Pi on made the difference. Honestly we're not 100% sure. Sometimes Linux just works and you don't fully know why.

We'll take it. 😄

Your First SSH Session

After all that, this happened:

flynn@pibox:~ $

That's it. That's the moment. A blinking cursor on a Linux server I built myself, connected to from my Mac, over SSH, just like I connect to EC2 instances at work.

It sounds simple. It wasn't. And that's exactly why it felt so good.

There's something genuinely satisfying about the first time you SSH into a machine you built from scratch. Not a cloud instance someone else provisioned. Not a VM spun up in seconds. A physical computer you assembled with your own hands, that you flashed an OS onto, that you troubleshot through an hour of network weirdness, that is now sitting on your desk blinking a little green LED.

Worth every one of those 21 cents over budget. 😄

Building the Stack

One of the first goals was to build a proper Java web stack, somewhat mirroring what I work with professionally.

Apache as the web server, MySQL for the database, Java 21, and Tomcat as the application server. The same basic architecture running on production servers everywhere.

Here's what that looks like on Ubuntu Server:

sudo apt install apache2 -y
sudo apt install mysql-server -y
sudo apt install openjdk-21-jdk -y

Three commands. Three major pieces of infrastructure. That's the beauty of apt, Ubuntu's package manager. It handles dependencies, downloads, installation and service registration automatically. No hunting down installers, no manual configuration, no dependency hell.

We installed Tomcat manually, downloading directly from Apache's servers. Trying to use a somewhat real world workflow, for learning purposes.

The final piece was configuring Apache as a reverse proxy in front of Tomcat. The browser talks to Apache on port 80, Apache secretly forwards requests to Tomcat on port 9090, Tomcat runs your Java app. The user never knows Tomcat exists. This is the standard production pattern, nginx or Apache out front, your app server behind it.

We built and deployed an actual WAR file. Opened it in Safari. It worked.

Full stack. On a Pop Tart. 😄

The AI Angle

Let's be honest about something: Linux man pages are not exactly light reading. They're comprehensive, technically precise, and about as approachable as a tax code. Claude bridged that gap constantly throughout this build, translating dense documentation into plain language, explaining not just what a command does but why you'd use it and what the output actually means.

A lot of times I knew what I wanted to do but couldn't remember the exact command, the right arguments, or where a particular config file lived in the directory structure. Claude is remarkably good at that translation layer, English to Linux and back again.

But here's what I think people miss about AI as a learning tool: the goal isn't to have it do the work for you. It's to have it walk alongside you while you do the work yourself. Every command in this build I ran myself. Every config file I edited. Every error message I read and tried to understand. Claude was there to help me understand what I was looking at, suggest what to try next, and explain why something wasn't working.

When something broke, and things broke constantly, we didn't just find a fix. We figured out why it broke. That's the difference between copying commands from the internet and actually learning Linux.

When I started out as a developer my resources were the public library, Yahoo chat rooms, and the occasional VHS tutorial. I'd visit the Programming and Computers chat room on Yahoo and ask: "Is anyone here a computer programmer?" hoping someone would help me figure out what I was doing. AI is that person, available at any hour, with no judgment, with patience that doesn't run out, and with knowledge that's actually current.

The whole setup would have taken significantly longer without it. It was like having an expert DevOps engineer sitting next to me the entire time.

Learn how, when, and where to use AI. That's the skill. Not whether to use it.

What's Next

This is just the beginning honestly.

The Java stack is up and running but there's a whole roadmap ahead. Next up is Docker, containerizing the same stack we just built manually. There's something valuable about doing it the hard way first, installing everything by hand, understanding what each piece does and why it's there. Then Docker makes a whole lot more sense.

After Docker, Kubernetes. Specifically k3s, a lightweight Kubernetes distribution built for small machines like the Pi. Then Terraform for infrastructure as code. The full modern DevOps stack, on a Pop Tart.

Eventually I want to deploy an actual project onto this box. Something called Dork Bear Records, a learning project I've been building to sharpen my SQL and Java skills. A real app, on a real server, that I built and configured myself. That's the goal.

And somewhere in there I want to spin up some old Unix distros. See what it was actually like for programmers in the 70s and 80s. Get a feel for where all of this came from.

The Pi is the perfect machine for all of it. Cheap enough to be fearless. Powerful enough to be useful. Small enough to fit in a shirt pocket.

If you're a developer looking to learn more about Raspberry Pi, Linux and server knowledge, build one. Seriously. And bring Claude along for the ride.