Setting Up a Server
DevOps has always been the one domain of software engineering that genuinely intimidated me. I loved frontend development; the instant feedback loop, the visual payoff of watching something come together on screen. I learned backend because I had to support what I was building on the front. But hosting? Deployment? Networking? I never touched it. Vercel and Heroku existed, and that was enough for me to never think about what happened after I pushed to main.
That changed at Wayfair.
When I got the internship, which is a story of its own, I submitted my team placement preferences and put devops dead last. My luck served me the way it always does, and I got placed on the networking team. I walked in on day one with no idea how any of it worked. But thanks to an immensely patient manager and an unhealthy reliance on AI, I was gradually taught the nuances of networking on the cloud. Subnets, DNS resolution, load balancing, routing, all the things I'd been happily ignoring for years suddenly had my full attention.
That internship planted a seed. Fast forward a few months, and I'm running Workbench out of our own office with a cloud bill from GCP that keeps climbing. The idea came naturally: an on-prem server would cut costs, but more importantly, it would give me an excuse to go deep on networking in a way that managing cloud services never quite does.
---
Choosing the hardware
The first rabbit hole was figuring out what to actually buy. I explored three routes: prebuilt rack servers, which were fucking expensive; cobbling together a rack from secondhand parts, which felt like a gamble; or just buying a PC. A prebuilt PC ended up being the right call, partly because of the ongoing RAM crisis making custom builds unafforable, and partly because I wanted something I could have running the same week I ordered it.
A week later, a Lenovo machine showed up at the office. 24 threads, 64GB of DDR5, and absolutely zero idea what I was about to put it through.
---
Building the stack
I started with Proxmox as the hypervisor because my old manager at Wayfair had recommended it months earlier when I asked him where to start. The install was straightforward, and within an hour I had a bare metal virtualization layer running. Then came the real question: what to actually do with it.
The original goal was simple. Workbench's staging and preview environments were running on GCP, and moving them on-prem would save us real money. But getting there meant solving a chain of problems I hadn't anticipated.
DNS was the first wall. I set up Pi-hole in a Debian container easily enough, but making it useful meant rethinking how our entire network resolved hostnames. I wanted internal services reachable by name, not IP address. After a long call with our ISP, during which I had to politely convince them to let me point our network's DNS to our own server, I got it working. Every service I spun up from that point forward could live behind a clean hostname.
Reverse proxying came next. I deployed Nginx Proxy Manager so every internal service could sit behind a proper domain with HTTPS, instead of forcing people to remember port numbers. Between Pi-hole handling resolution and Nginx handling routing, the network was starting to feel like an actual platform rather than a machine sitting in a closet.
Then came the deployment pipeline. I could have just SSH'd into the box and run docker compose like a normal person, but that felt like a waste of having the infrastructure. I set up Portainer for container management and observability, built a private Docker registry on-prem to avoid paying for cloud registry costs, and configured a local GitHub Actions runner that builds our Docker images on push to staging and drops them straight into the local registry. Some finessing later, our staging instance was fully running on-prem: built, deployed, and served without touching a cloud provider.
The VPN problem was inevitable. The moment we had services worth accessing, we needed to reach them outside the office. I set up Tailscale (shoutout to them being from Toronto) and within an hour we had a mesh VPN that let the team connect to the local network from anywhere. Staging, Pi-hole admin, Portainer dashboards: all accessible as if you were sitting at the office.
---
The fun stuff
Once the core infrastructure was solid, the server became a playground.
We're an AI company, so the obvious next move was running models locally. I deployed Ollama on a pod with Open WebUI as the interface, and we can now comfortably run models up to 30B parameters. Nothing groundbreaking on CPU alone, but more than enough for testing and experimentation without burning API credits.
That led to setting up an instance of OpenClaw for deep research. We use it to run background research on market positioning, competitive shifts, and strategic questions, the kind of work that used to eat through tokens fast. Having it run locally and continuously was a meaningful win.
The last addition was an Acumatica sandbox. Workbench integrates with ERPs, and Acumatica offers a free sandbox environment that has to be deployed on Windows Server. So I spun up a Windows Server container and got a full ERP instance running on-prem for client demos. It's not glamorous, but it means we can walk a prospect through a live agent-to-ERP flow without depending on anyone else's infrastructure.
---
What it taught me
The server itself was a project. But what it actually gave me was a working understanding of things I'd been abstracting away for years: DNS resolution, DHCP, internal routing, host management, container orchestration at the metal level. The kind of knowledge you can't get from deploying to Vercel.
There's a long list of things I want to do next: throw a GPU in the machine and run real models, explore whether on-prem inference can handle production latency for deployed agents, maybe build Vercel-style preview deployments on PR for our Kubernetes-powered backend. The server is infrastructure, but it's also a sandbox that keeps generating new problems to solve.
And that's the part I keep coming back to. The cloud bill was the excuse. The curiosity was the reason. I wanted to understand how it all worked from the inside out, and the only way to do that was to build it myself.
If you've been thinking about setting up a server of your own, do it. The possibilities are endless, the hair loss is inevitable, and it's all worth it in the end.