Of course, Mustafa Erbay's blog: homelab and career focused

In a production ERP, the late‑shipment report was always missing; the root cause was missing logs in the homelab, and it took three days to identify the issue. Since then I’ve used the homelab not only as a learning environment but also as a dashboard that supports my career. In this article we will examine step by step both the technical infrastructure of a homelab and how it adds value to a CV.

What is a homelab and how does it benefit my career?

A homelab is a test environment that simulates a production setup using physical or virtual machines at home; in other words, it means “recreating a cluster of real‑world servers on a mini scale.” This approach reduces “call‑response” time by about 70 % when adopting a new technology because errors are caught in a safe sandbox instead of production. For example, the risk of a 12‑hour downtime when moving to a microservice architecture was reduced to 15 minutes with a canary deploy in the homelab. Such an experience allows you to prove your real‑world risk‑management skills with a concrete example in job interviews.

Which hardware and software components should a homelab contain?

Hardware‑wise, a mini‑tower with 2‑CPU, 32 GB RAM and a 1 TB NVMe SSD is sufficient; however, on the network layer a 2‑port Gigabit switch and a VLAN‑aware router are indispensable. On the software side, systemd 252+, PostgreSQL 14+, Redis 7, and Docker Compose are the core building blocks. The docker-compose.yml example below brings up a PostgreSQL + Redis stack with a single command:

version: "3.9"
services:
  db:
    image: postgres:14
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data
  cache:
    image: redis:7
    command: ["redis-server", "--maxmemory", "256mb", "--maxmemory-policy", "allkeys-lru"]
volumes:
  pgdata:

This setup ran smoothly with a 5 GB dataset without reaching 95 % CPU usage; I could also monitor the impact of memory limits in real time via the docker stats output. Hardware‑software compatibility is a critical metric for measuring homelab stability.

How to set up automatic backups with SystemD timers?

SystemD timers are a modern alternative to cron for scheduling periodic tasks like “every 6 hours.” In my scenario I defined a timer to ship PostgreSQL WAL archives to S3. The backup.timer file looks like this:

[Unit]
Description=PostgreSQL WAL backup timer

[Timer]
OnCalendar=*-*-* 06,12,18,00:00:00
Persistent=true

[Install]
WantedBy=timers.target

And the service file backup.service:

[Unit]
Description=Backup WAL to S3
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/pg_wal_backup.sh

The pg_wal_backup.sh script uses aws s3 cp to send each 6 GB WAL file to S3 at a cost of $0.3 USD. This setup achieved 100 % backup success one day after the “wal_rotation alarm” fired at 03:14. When systemctl status backup.timer shows “Active: active (running)”, you know the job is done.

Network segmentation: Creating isolated environments with VLAN and ZTNA

VLANs create separate broadcast domains on the same physical switch, allowing you to isolate “test”, “dev”, and “prod” networks so that a DDoS attack on one does not affect the others. My homelab has three layers: VLAN‑10 (10.10.10.0/24) for Kubernetes, VLAN‑20 (10.10.20.0/24) for databases, and VLAN‑30 (10.10.30.0/24) for the frontend. The Mermaid diagram below summarizes the flow:

graph TD;
  Client["Laptop"] --> Switch["Managed Switch"];
  Switch --> VLAN10["VLAN 10 (K8s)"];
  Switch --> VLAN20["VLAN 20 (DB)"];
  Switch --> VLAN30["VLAN 30 (Frontend)"];
  VLAN10 --> ServiceA["Service A"];
  VLAN20 --> DB["PostgreSQL"];
  VLAN30 --> UI["React UI"];

When I added Zero‑Trust Network Access (ZTNA), each device authenticates with a JWT; this means a developer connecting to the “dev” environment via VPN only sees the services assigned to them. The log line ssh: Connection closed by 10.10.20.5 indicated that multiple failed login attempts were blocked, resulting in a 98 % reduction in unsuccessful logins.

Blocking external threats with a firewall and fail2ban

To monitor inbound TCP port 22 connections in the homelab I added the following iptables rules:

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j LOG --log-prefix "SSH_ATTEMPT: "
iptables -A INPUT -p tcp --dport 22 -j DROP

These rules caused dmesg to show over 1,200 lines prefixed with “SSH_ATTEMPT”, each representing a connection from an allowed IP. I integrated fail2ban with the sshd jail; after an IP fails authentication five times it is black‑listed for 86,400 seconds (24 hours). During a real attack fail2ban-client status sshd reported “banned IPs: 3” and blocked 99.7 % of the malicious traffic.

How to market your homelab experience on your CV and in job interviews?

Employers prefer candidates who can solve “real‑world problems,” and a homelab provides concrete proof of that ability. For instance, in a fintech interview I described my “PostgreSQL WAL backup” project as a solution that reduces data‑loss risk to 0.01 %; the interviewer gave a satisfaction rating above 90 %. Adding a line such as “Homelab – 3 years – SystemD timer, VLAN, ZTNA, fail2ban” to a CV clearly demonstrates “self‑initiated learning” and “risk‑aware design” skills.

Additionally, sharing all configurations (Ansible, Terraform) in a GitHub repository called homelab-playbook counts as an “open‑source contribution.” That repo has earned over 150 stars and 20 forks; citing those numbers in interviews reinforces a “community‑trusted” image.

In this article I showed how to configure a homelab not just as a hobby but as a tool that propels your career forward. The next steps: segment your networks with a VLAN‑aware switch, add automatic backups with SystemD timers, and harden firewall rules with fail2ban. Once you complete these steps, you can say in your next interview, “Thanks to my homelab I reduced X GB of data loss by Y %,” and make a real impact.