Intro

So as my girlfriend Emma and I setup the logistics of our new apartment in Boston, we quickly figured out that we had many accounts that would really be joint, but only filed under one person's name. Some of the bills were in my name, such as internet, while others were under her name like gas and electric, yet I felt that we both should have access to the accounts in case we needed to get a bill paid quickly.

Also, being two security minded people, Emma and I both use Bitwarden to create new passwords on the sites we visit so we have strong, unique passwords to our accounts. This makes it so that if one company has a data breach, not all of your accounts are leaked. However, Bitwarden only offers password sharing between organizations, which is a premium feature for the hosted service. However, since Bitwarden is open-source, you can self host the premium version on your own hardware if you would like and unlock all of the features. Since I was already paying for the kubernetes cluster that is hosting this blog, I figured I would throw a bitwarden server behind my traefik instance and utilize the nodes a little more efficiently. Two birds with one stone.

Research

So initially, while looking up bitwarden self hosted options, I first landed on the official Bitwarden Github Page. It looks like it could be run with Docker, which means that the image is hosted somewhere, which is perfect for what I needed!

However, as I started to do more testing locally with the docker image, the official image seemed to be very resource heavy... Ok, not that resource heavy, but certainly more than I wanted since it required an instanced of sql server to be running. So, I started to look for other open source projects around the web and stumbled upon bitwarden_rs. It is the Bitwarden API written in rust and it's rocket server. This was exactly what I was looking for. A lightweight, simple Bitwarden server that could write to small sqlite3 instanced inside the container in the /data directory.

I also really loved that Bitwarden unofficially supports bitwarden_rs and actually files issues in their github if problems arise. On the flip side, bitwarden_rs actively encourages their users to contribute to upstream development, whether it be through financial contributions or fixing bugs. So if you are following along with this blog, please consider donating to this wonderful service.

Implementation

The first thing I did before deciding on bitwarden_rs was read over their entire wiki which you can find here. If I miss anything in this blog article, I guarantee you it will be in their wiki, and I encourage my readers to also read the wiki before following along. It will help you understand my implementation further, and maybe even find things I have missed.

Next, I dove into creating the kubernetes manifests. Since bitwarden_rs maintains a public docker image, it was pretty easy to get the Kubernetes deployment going. You can find the code below, with short explanations after each snippet:

The blog series are living documents, so I will be updating the specific articles or adding new ones as I continue to fine tune my home lab cluster.

The code for all of these articles in located on my Gitlab.

Intro

Holy vacation, Batman! I've been gone for a while, and haven't been as active on my blog lately, but I promise that it was for a good reason. I've finally started my homelab, and have some really exciting content to share with the void.

As mentioned in my Running bitwarden_rs on Kubernetes blog post, I planned on running my own kubernetes cluster at home. Back in my junior year of college, I happened to land on a project with a peer of mine named Jason (Jason, if you're reading this, thank you!). He happened to have an old server chassis laying around that he was willing to part ways with. The server chassis was a Chenbro RM21706, but had no drives, no motherboard or compute components, and only included the RAID card, chassis fans, and power supply. However, it was the beginning of a server, and I was determined to have it be my server. Quickly, I found an ATX-E motherboard on Facebook marketplace with 2 Quad Core Xeon processors, their cooling blocks, and 32GB of DDR2 RAM (yes, you read that right). However, the motherboard only cost me a whopping $25, so I couldn't pass up the chance to boot up this server and get it running. After buying it from the seller, rushing home and ripping the top panel off of the chassis, I was on my way to starting this thing up.

However, I quickly found out that the old motherboard I had bought was LOUD, like really loud. When I turned the thing on, even in our storage closet, it sounded like a vacuum cleaner was running in the other room. The old Intel CPU cooler ran at super high RPMs, and I didn't want to mess with the BIOS to get the noise level down when I could invest in something a little more modern. This would also allowed me to keep the power costs down, as I was going to be running this in my home 24/7. The Chenbro was fun to play around with, but for running a 24/7 server with home utilities, it was just too loud and power hungry. So instead, I decided to invest around $400 in a new (to me) Dell r620. This little 1U server was not only much more power efficient, but it also was much quieter than the old Chenbro, even being a 1U. The specs of the machine are as follows:

• CPU: 2x Intel E5-2670
• RAM: 128 GB DDR3
• 8x 1TB 2.5in Seagates

I threw the thing in my server box and booted it up. Looking at my Kill-A-Watt, the new R620 would cost me around $12/month to run 24/7. Great, much cheaper than the $50 I was spending on a minimal kubernetes cluster in the cloud.

Setup

First, I had to install Proxmox on the servers. I decided to go with Proxmox because it is really just a modified version of Debian under the hood, and for my home environment, I would rather have something I am familiar with instead of something that is "more secure." This kind of led me to stray away from ESXi and other platforms, which instead have custom kernels for virtualization. After I grabbed the latest Proxmox image, I dd'd the ISO to a space USB drive I had laying around to create a bootable disk.

Oh my, it has been a while since I have posted a blog. One of my new years' resolutions for 2025 is to become healthier, and I am sure many of you reading this can relate to that. Part of that mission for me is to express a lot of the goals and ideas I have with the software community at large, as well as write some of my own projects, scripts and ideas down so that I can refer back to them later. Hopefully this will inspire some of you to do the same.

With that, I figured the first part of this journey would be to write an article about the evolution of the hardware I run at home, how it's setup, and where I see it going in the future. This article is mostly going to be a high level overview of my hardware and the tools I run on it so that I can provide some context to the future articles I plan on writing. Stay tuned for those.

I sometimes pause during the day to laugh at how much like my father I am becoming. There are many times when I catch myself thinking or acting in a way that I know he would and it makes me reflect on how much wisdom was in a lot of his actions. Pops, if you're reading this - thank you.

I remember being younger and scoffing when he brought up the idea of getting security cameras for their new house. My whole life my parents have lived in remote locations with lots of land, so the idea that someone would travel out into the country to find a single door on a single house seemed foreign to me. Also - once criminals were out there in the country, they likely had already decided to commit a crime. What would video cameras do to prevent it?

However, what I had not considered at the time was that the idea was not to prevent the crime from happening, but rather know about the crime quickly and respond immediately. Crimes are often unpreventable and unavoidable - it often comes down to bad luck. The idea is knowing when you are unlucky.

So, naturally, as I began my journey of self-hosting software I use daily, I began to wonder...

AI hype is everywhere in the tech landscape today, and there are many rumors and falsehoods about it's value. It feels like everybody from large corporations to aspiring startups are lunging at the opportunity to insert AI into their tools and products to capture their share of the tech angel investing budget.

Personally, I think that AI is a crucial tool, but like any tool, it has its good use cases and then use cases that it just doesn't excel at. Maybe this statement will age like milk in the future, but I'm fairly confident that AI in March 2025 is a glorified text generation tool. However, like any tool, I do realize that my own bias comes from the bad anecdotes I've seen in person and read online. I don't actually understand how AI works behind the scenes, I just see the final "products," even if they aren't necessarily applied to the correct or appropriate use cases. So, I set aside some time this spring to truly sit down with a good friend of mine and genuine learn what AI has to offer and how it works at a lower level.

But first, let's check out some final graphs showing the data + context I used to keep everyone engaged. This same context eventually is fed into the ML training loop and used to train the AI.

TL;DR: I setup my home networking with virtualized Opnsense and piHole. Yes, it is overly complex, but I kept my networking knowledge somewhat sharp.

I've always been curious about networking infrustructure, ever since the early days of my prepubescent childhood. I remember when I first got my xbox 360 around my 6th grade birthday, I immediately was curious on how it connected to the internet, how it connected to xbox's servers, and how hostbooters were able to find my "address" called an ip address and kick me offline. For those who don't know, "hostbooting" is gamer slang for a DoS attack on a client's public ip address. Essentially flooding their home network with packets to disconnect them from online gaming services. People would disconnect players on the other team for an easy win.

Anyway, that passion always carried itself with my all the way until my first intership at Datto, where I was pulnged head first into the world of networking. I remember going into the job thinking: I've been programming for over 3 years at this point. I'm pretty comfortable with computers, and have programmed a few things into my raspberry pi. I can handle this internship.