I’ve been planning out what I want to build in my homelab, and the possibilities are… endless. Exciting and mildly overwhelming at the same time. Here’s where I finally landed: I’m using a Lenovo ThinkPad L13 Yoga (i3-10110U, 8GB RAM, 256GB SSD) running Ubuntu as the base for a K3s cluster. Not exactly a data center powerhouse, but perfect for learning Kubernetes fundamentals without smoking my electric bill. The Project Goal I’ve got a Google Nest (Gen 3) thermostat, and I want to pull real-world energy data out of it to analyze: - How often the furnace or AC runs - Average indoor temps - Seasonal patterns - Whether this thing is actually saving me money or just looks fancy Like I said, the laptop will be the cluster running multiple pods, and I plan to visualize everything in Grafana. I’ll figure out the guts in between. I learn best by doing — and doing something that actually interests me. IMO, this beats wandering through a course without a purpose. The Plan - FastAPI microservice to fetch & normalize Nest data - Store data in Postgres - Deploy everything in K3s (Deployments, Services, Ingress) - Visualize with Grafana - (Eventually) automate deployments via GitHub Actions → K3s Thoughts?

Today I had a small realization that might be useful for anyone getting into Linux. When you’re trying to pick your first distro or you just want to see what other ones offer, you don’t actually need to install them directly on your machine. Instead, you can just set up a simple virtual machine on your PC, test a few distros, and see which one fits your style. Personally, I never thought about doing that. Jumping straight into Arch seemed the most fun way because I enjoy the idea of building everything from scratch. But if you’re just starting out and want to test distros, setting up a VM first can save you a lot of time and make the choice easier. Just wanted to share this little tip in case it helps someone out here so you can be like the guy in the gif hahah

Successfully set up Terraform for my personal site today—without nuking AWS. 😅 Terraform can be intimidating. One wrong command and you can wipe out your infra. Learned that the hard way on a QA stack with CloudFormation. Today I wanted to import my existing AWS setup—S3, ECR, CloudFront—into Terraform. I skipped Route 53 for now (curious if anyone thinks I should include it). The Approach: Started manually with S3 resources—good way to understand the infrastructure. CloudFront? For me it seemed complex to write by hand, so I used Terraform’s generate-import feature and it worked surprisingly well. Then I imported my ECR repo the same way. Configured an S3 backend for Terraform to store the state, making my infrastructure safe, reproducible, and ready for CI/CD. Then, I ran terraform plan to verify changes (only added some tags). Adjusted IAM permissions—AWS threw a few 403s—but once fixed, terraform apply went smoothly. Verified my site was up and all resources are intact. Takeaways: I now have an automated, reproducible infrastructure without downtime or risk. Terraform v1.5 import improvements make managing existing infra much safer. Doing some manual work first gives better understanding and control. Next Steps: Integrate Terraform into GitHub Actions with secure secrets. Build Terraform configs for a Dockerized environment. Explore Kubernetes: EKS or K3s locally. TL;DR: I now have a safe, reproducible setup for my site. Learned a lot about Terraform imports, IAM permissions, and CloudFront quirks. Ready to apply these lessons to bigger projects. Have you ever used Terraform and what are your thoughts on the generate configuration feature? Always open to feedback. Here's my current folder structure for my .tf files.

A while ago, I got a DevOps interview challenge that pushed me to level up — even though I didn’t land the job, the learning was worth it. The task?1️⃣ Build and deploy a Dockerized Laravel app through a Jenkins pipeline (image, tests, release).2️⃣ Design a scalable AWS stack using RDS, EC2, S3, Lambda, ECS, SNS & SQS.3️⃣ (Optional) Scale workloads on DigitalOcean droplets with monitoring and backups. Instead of stopping there, I decided to build the full project myself and document everything here 👉 parcelpro-starter. It became a great learning curve — proof that every interview, even the ones you don’t pass, can be a springboard for growth. 💪 In DevOps, upskilling never ends. Every tool, every lab, every project builds your confidence for the next opportunity. 🚀