Starting Over Without Starting From Scratch

There comes a point when you look at something you've been building for years and wonder whether it would be easier to tear it all down and start again.

That was more or less where I found myself at the beginning of June 2026.

I had what I loosely considered a home lab. There was an ageing MacBook running Ubuntu Server, a collection of networking equipment, some Raspberry Pis and several computers that had either been repurposed or were waiting to be useful again.

Things worked. Mostly.

I had Jellyfin running, Cockpit for management, experiments with Ollama and a few other services that had accumulated over time.

But the environment wasn't particularly organized. Some things had been configured because I needed them at the time. Others existed because I wanted to experiment with something new.

I could make things work, but I couldn't necessarily claim that the environment had been designed with any real intention.

And increasingly, that bothered me.

A collection of experiments isn't necessarily a lab

I enjoy working with technology. Much of what I've learned throughout my career has come from working through problems, experimenting and figuring things out.

That curiosity doesn't switch off when I leave work.

Over time, the equipment I had available became an opportunity to explore things I might not ordinarily get to experiment with in a professional environment.

My old MacBook Pro, for example, had become an Ubuntu server. It wasn't particularly powerful: a dual-core Intel i5, 8 GB of memory and a modest SSD, supplemented by an external media drive.

It was also connected over Wi-Fi.

For a few services and occasional experiments, it was useful. But I was beginning to ask more of it than I had originally intended.

I wanted to explore virtualization, better network management, centralized DNS, automation, monitoring and eventually cybersecurity experimentation.

I also wanted documentation that was more meaningful than a collection of screenshots and notes I might struggle to find six months later.

The problem wasn't necessarily the equipment.

It was the absence of a coherent plan.

The temptation to start from scratch

My initial thought was to scrap the existing arrangement and rebuild everything.

New naming conventions. A better physical network. Clearly defined services. Proper documentation. A virtualization platform rather than another collection of applications running directly on whatever computer happened to be available.

I even started thinking about what new hardware might make the most sense.

But before committing to purchases, I decided to examine what I already had.

There were Dell OptiPlex machines, Lenovo laptops, two Raspberry Pis, a UniFi access point, a Cloud Key, a UniFi Security Gateway and various switches.

Some were operational. Some hadn't been used in a while. Others weren't even powering on properly.

And that became the first real exercise.

Instead of designing around what I wanted to buy, I would design around what I could actually make work.

The Dell OptiPlex that wasn't quite dead

One of the available systems was a Dell OptiPlex 7010 Small Form Factor.

It had seen better days.

When I began examining it on 3 June, it wasn't a functioning server candidate. I was dealing with an amber power indicator, diagnostic beeps and uncertainty about the condition of its components.

As it turned out, the machine initially had no memory installed.

After fitting a spare DDR3 module, I managed to get into the BIOS. The machine recognised the RAM and I could begin investigating the processor, storage and other components.

That was encouraging.

I had several old OptiPlex machines available, which meant I could recover parts rather than immediately purchasing replacements.

By 5 June, the system had come together.

It had an Intel Core i7-3770 processor, 20 GB of DDR3 memory, a 500 GB SSD and a 1 TB hard drive.

There was still a problem with one of the memory slots, but I had a working machine with enough resources to begin experimenting with virtualization.

It wasn't new, powerful or particularly elegant.

But it could do the job.

And there was something satisfying about that.

I had gone from investigating why an old computer wouldn't start to preparing it as the foundation of a completely rebuilt environment.

Sometimes the biggest improvement is a cable

There was another issue I needed to address before moving forward.

The internet connection entered the house downstairs. A CAT6 connection already ran to the Linksys router in the upstairs living room, where some of the networking equipment was located.

My lab equipment, however, was in a bedroom.

Rather than running another cable, I had been relying on Wi-Fi for convenience.

That was fine for ordinary use, but it wasn't how I wanted to operate a server hosting several persistent virtual machines and network services.

So I ran and terminated a CAT6 cable between the living-room networking equipment and the bedroom.

I tested the connection, brought a switch online and connected the main workstation and the newly recovered OptiPlex.

Nothing particularly sophisticated happened.

But suddenly I had a much more dependable physical foundation for the work ahead.

It also reminded me of something that is easy to overlook when you're excited about virtual machines, automation and security tools.

Sometimes the most important improvement is getting the basics right.

Getting serious about documentation

Around the same time, I began organising the project on GitHub.

This was another learning exercise in itself.

I'd worked with code and development tools before, but I hadn't developed a particularly disciplined approach to version control.

I was familiar with the problem of accumulating files called something along the lines of v1.0, v1.2, final and really final.

I didn't want my lab documentation to become another version of that.

So I began with a single repository and Markdown documents for the equipment inventory, architecture, decisions, roadmap and development history.

At first, even that felt a little excessive. I found myself creating files and wondering whether I was spending more time organising the project than actually building it.

That was a useful early lesson too.

Documentation needs a purpose.

I didn't need to manufacture an impressive-looking collection of documents. I needed enough structure to explain what existed, why I made decisions and what happened when something changed.

The documentation would evolve alongside the environment.

The first real milestone

By 6 June, the recovered OptiPlex was ready to become the first Proxmox server.

This marked the point where CMR Lab began transitioning from a collection of individual systems into something more deliberate.

The original MacBook had served its purpose, but it was no longer the right foundation for what I wanted to accomplish.

With Proxmox, I could begin separating responsibilities: management utilities, network administration and application hosting could each have their own environments.

At least, that was the plan.

I would soon discover that installing a virtualisation platform was only the beginning. Processor compatibility, storage configuration, application dependencies and networking would all introduce their own challenges.

Some of those problems would turn out to be considerably more interesting than the installations themselves.

Why I'm documenting this journey

CMR Lab isn't an attempt to build the most powerful home lab or collect the largest number of running services.

It's an opportunity to understand technology more deeply through practical experience.

I want to be able to explain not only what I've deployed, but why it was necessary, what alternatives I considered, what problems I encountered and how I determined whether something actually worked.

There will be mistakes, decisions I'll reconsider and experiments that don't go according to plan.

I'm not particularly interested in editing those parts out.

They're often where the learning happens.

And if documenting those experiences helps someone else approach a similar problem with a little more understanding, that's worthwhile too.

For now, the first milestone was relatively simple.

I had taken an unreliable collection of equipment, recovered an old computer, improved the physical network and established a foundation for the next stage.

I hadn't really started from scratch.

I'd started by understanding what I already had.

---

CMR Lab's technical architecture, decisions and supporting records are available in the GitHub repository.