Sometimes an upgrade is not about buying something new. Sometimes the better move is taking the thing that is already sitting there and giving it a better job.
That is what happened to my old gaming PC. It used to be the center of my gaming setup. Now it is a small home server running databases, backends, and the kinds of things I do not want to pay for as another separate service.
Why I stopped using the desktop
I have been gaming on PC since I was very young, so that machine had a long run. But this year I bought a MacBook Air, and it slowly became my main computer for almost everything: work, personal projects, writing, Codex, and quick ideas away from the desk.
That changed more than I expected. I did not want to be tied to one setup anymore. I wanted to open the laptop on a train, at school, on a sofa, or wherever else and just continue.
So the desktop stayed powered off more and more. And when I want to play something now, GeForce NOW from the Mac is usually enough. The old PC was good for its time, but it was starting to hit performance walls as a gaming machine. As a server, it still made perfect sense.
I did not want every small idea to become a subscription
A lot of my projects need some backend, database, auth, or small internal tool. Managed services like Supabase are comfortable and absolutely have their place. But when I build lots of small things for fun, paying separately for every tiny project stops making sense.
This was not about saving money at all costs. It was more about removing a bad filter from the way I build: “Is this idea worth another monthly bill?” That is a bad question to put in front of creativity.
Now the server can hold small databases, test services, and backends for projects like EasyFlex, ABRA Flexi AI, and even the database side of this portfolio website. It also gives me space for more experiments that would otherwise stay in notes.
Installing Ubuntu was not exactly smooth
The setup itself was not some clean cinematic montage. It was more like a few failed boots, trying to hit the right boot-menu key, dealing with small annoying issues, and finally getting into the Ubuntu installer.
I kept the setup as minimal as possible. No unnecessary desktop environment, no giant experiment on day one. The goal was simple: the server should run, host things, and stay out of the way.
That matters. Home infrastructure can easily become another project that eats more time than it saves. I wanted the opposite.
Cloudflare Tunnel beat messing with my router
The next decision was networking. I did not want to expose my home router or deal with port forwarding, public IPs, NAT, and all the usual small traps. I used Cloudflare Tunnel instead.
That worked surprisingly well. The tunnel runs on the server, I map a service to a domain, and I do not have to open random things directly through the router. It is boring in exactly the right way.
Then I started moving hosted things over. Some apps needed different env vars. Some expected a different Node version. Some worked locally and then broke in a completely different way on the server. But that is the normal cost of owning more of the stack.
It became a server when I unplugged the monitor
Once the setup was stable enough, I unplugged the monitor. From that point it stopped feeling like “a computer under the desk” and started feeling like a server.
At first I accessed it through Tailscale, later mostly through SSH with public/private key auth. I also wanted to remove the GPU to save more idle power, but my Ryzen 5 3600 setup will not boot without it. So the GPU unfortunately stays.
It is not perfect. But it is still much better than letting the whole machine sit unused.
Codex became part of the server workflow
The next obvious step was installing Codex. Not only for working on projects, but also for managing the server itself.
These days I do not manually SSH into it nearly as much. In the Codex app on my Mac, I have a connection that lets the agent work directly on the Linux server. In AGENTS.md and a custom skill, I describe what the server is, where projects live, how it should behave, and what it can safely do.
I sometimes use Claude too, mostly when I want a different angle on UI or frontend work. But for normal server tasks, the interesting part is that Codex can work right next to the infrastructure.
In practice, that means I can ask it to help with things like:
- moving a small service,
- checking logs,
- preparing a deployment,
- cleaning up
/srv/projects, - setting up a new database or backend quickly.
I still need to understand what is happening. That part does not disappear. But I do not have to copy the same commands again and again.
What I learned from it
I am not saying self-hosting is always better than managed services. It is not. If a project is critical, needs high uptime, has a team behind it, or requires quick support, a managed platform makes a lot of sense.
But for personal projects, prototypes, small databases, and things I want to build quickly without a small mental tax, having my own Linux server is great. It also fits parts of my portfolio and website work, where a small piece of infrastructure does not always need a large platform around it.
Mostly, I like that the old gaming PC did not become a dust collector. It used to give me performance for games. Now it gives me room to build small things without attaching another account to every idea.
That is a pretty good second career for an old PC.
Top comments (1)
This post is a great example of how far “old hardware reuse” has evolved beyond just nostalgia—it’s now a practical entry point into self-hosting and home labs.
What stands out is the mindset shift: instead of treating a retired gaming PC as e-waste, it becomes a flexible infrastructure node. With Linux, tools like Docker, and lightweight server distributions, even older consumer hardware can reliably run services like file storage, media streaming, automation, or private cloud setups.
I also like the implicit theme here: control and ownership. Running your own Linux server means you’re no longer dependent on third-party platforms for basic services like backups or media access. That aligns with a broader trend in the dev community toward self-hosted ecosystems and “build your own cloud” setups.
Of course, the hidden tradeoff is responsibility—power management, security hardening, networking, and maintenance all become your problem. But that’s also where the learning value is.
Overall, this kind of setup is one of the most practical ways to learn real-world DevOps concepts without expensive infrastructure.