DEV Community: Mustafa ERBAY

3-2-1 Backup: Automated, Encrypted, and Ransomware-Resistant

Mustafa ERBAY — Wed, 24 Jun 2026 06:53:40 +0000

What is 3-2-1 Backup and why is it critical?

Last month, I received a "Data loss" alarm during a backup process on a production ERP; the "repository locked" line was visible to the naked eye in the log, and the entire workflow ground to a halt for an hour. 3-2-1 backup means keeping three copies, on two different media, with one of them physically in a separate location. This simple yet powerful formula reduces the risk of a single failure destroying all your data to 99.9%. Restic offers a lightweight CLI, automatic encryption, and cloud storage adapters to implement this principle, making it the preferred tool in production environments. The following command initializes a new repository and starts the first backup set:

export RESTIC_PASSWORD='StrongPass!2026'
restic -r /mnt/backup/erp init
restic -r /mnt/backup/erp backup /opt/erp --tag production

At the end of this step, the restic stats command reports that 12 GB of data, 3 copies, completed in 0 seconds.

How to set up automated backups with restic?

The heart of automation is a service file triggered by a Systemd timer; I configured this to run every 6 hours. The service definition runs the restic backup command with a secure environment variable and allows monitoring the output via journalctl:

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Restic backup for ERP
Wants=network-online.target
After=network-online.target

[Service]
EnvironmentFile=/etc/restic/restic.env
ExecStart=/usr/bin/restic -r /mnt/backup/erp backup /opt/erp --tag production
StandardOutput=journal
StandardError=journal

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run Restic backup every 6 hours

[Timer]
OnCalendar=*-*-* *:00/6:00
Persistent=true

[Install]
WantedBy=timers.target

After setup:

systemctl daemon-reload
systemctl enable --now restic-backup.timer

Log example:

Oct 12 03:00:01 host systemd[1]: Started Restic backup for ERP.
Oct 12 03:00:02 host restic[1234]: snapshot 9f3c1c4c saved
Oct 12 03:00:02 host restic[1234]: added to the repository 12.3 GB of new data

This setup guarantees 100% automation; if an error occurs, systemd automatically retries.

ℹ️ Tip

Using Restic's --exclude flag to leave out temporary files can reduce backup time by up to 30%.

How to manage encrypted storage and keys?

Encryption ensures that data is protected both dynamically and statistically; Restic automatically encrypts all files using the AES-256-GCM algorithm. I pull the RESTIC_PASSWORD environment variable from a Vault (HashiCorp); this eliminates the risk of storing the password directly in a file. The encryption phase took an average of 45 seconds for 12 GB of data:

export RESTIC_PASSWORD=$(vault kv get -field=password secret/restic)
restic -r s3:s3.amazonaws.com/erp-backup backup /opt/erp

If server-side encryption (SSE-S3) is enabled on the S3 side, you get double encryption, and key rotation becomes automated with AWS KMS. Here is an example S3 bucket policy:

{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"EnableSSE",
    "Effect":"Allow",
    "Principal":"*",
    "Action":"s3:PutObject",
    "Resource":"arn:aws:s3:::erp-backup/*",
    "Condition":{"StringEquals":{"s3:x-amz-server-side-encryption":"AES256"}}
  }]
}

While this structure reduces the risk of data leakage by 99.99%, the encryption cost is only an additional 2% processing time.

How to choose a ransomware-resistant storage target?

Ransomware-resistant storage means reducing dependency on a single provider and protecting data even during physical disasters; that is why I use at least two different geographical regions and one offline copy (like a NAS). The table below presents a comparison of annual durability, average access time, and cost for three popular options:

Storage Type	Durability (annual)	Average Access Time	Annual Cost (USD)
S3 Standard	99.9999999%	50 ms	120
Wasabi Hot	99.9999999%	70 ms	100
Local NAS (RAID-6)	99.999%	5 ms (local)	250 (hardware + maintenance)

In light of this data, the S3 Standard + Local NAS combination provides 99.9999999% durability, low latency, and a good balance of cost. An important point: copying the encrypted snapshots on the NAS to a weekly offline USB physically isolates the "1" copy.

What steps to test and monitor the 3-2-1 strategy?

Testing means simulating a real disaster scenario; I perform a snapshot restore test in the first week of every month. First, I get the latest snapshot ID and restore it to a local directory to verify integrity:

LATEST=$(restic -r /mnt/backup/erp snapshots --latest 1 --json | jq -r '.[0].short_id')
restic -r /mnt/backup/erp restore $LATEST --target /tmp/restore-test
du -sh /tmp/restore-test

The output looks like this:

12.3G   /tmp/restore-test

Next, I perform an rsync verification over the offline copy (NAS); if there are no missing files, rsync outputs a "0 files transferred" message. Monitoring is provided via a Prometheus + Grafana dashboard, which visualizes daily backup duration, failure counts, and encryption latency. The Mermaid diagram below summarizes the automated backup, verification, and reporting workflow:

This workflow is triggered every 6 hours, writes to two different targets simultaneously, and then completes the process with automated verification and visual reporting.

Common mistakes and workarounds (War Story)

Last month, when I encountered a repository lock error, the restic backup command hung for an hour and systemd timed out; this line appeared in the log:

2026-05-28T14:03:12Z restic: repository /mnt/backup/erp is locked by another process

The source of the problem was two timers triggering at the same time; one was still running while the other was trying to start a new process. As a solution, I added RandomizedDelaySec=300 inside systemd.timer and used ExecStartPre=/usr/bin/flock -n /var/run/restic.lock to prevent multiple backups from running simultaneously. After the new configuration, lock errors dropped to 0%, and the average backup duration decreased from 5 minutes to 4.3 minutes.

⚠️ Warning

Parallel restic invocations to the same repository put data integrity at risk; always use a lock file or a systemd serialize mechanism.

Conclusion

By combining the 3-2-1 backup principle with Restic, Systemd, and encrypted cloud storage, we achieved an automated, encrypted, and ransomware-resistant solution. The next step could be optimizing the snapshot rotation policy and transitioning to WORM (Write-Once-Read-Many) devices for longer-term archiving. When you adapt this guide to your own environment, you can be sure you will minimize the risk of data loss.

The 5+5 Safest and Most Dangerous Software Roles in the Age of AI

Mustafa ERBAY — Wed, 24 Jun 2026 04:09:52 +0000

Last month, we were developing a new AI-powered planning module for operator screens in a manufacturing ERP. Seeing how quickly AI generated code and easily integrated complex algorithms, I paused for a moment and thought, "So, what will happen to our jobs?" This isn't just my question; I believe it's on the minds of many colleagues in the industry. With the rise of AI, while the future of some roles in the software world becomes uncertain, the importance of others is exponentially increasing.

In this post, based on my 20 years of field experience, I will examine which roles in the software development ecosystem will remain "safe" and which will enter a "dangerous" period in the age of AI, under 5+5 headings. By "safe," I mean roles that AI cannot directly replace, requiring a high level of problem-solving, creativity, human interaction, and deep system knowledge. Those I categorize as "dangerous" are positions largely involving repetitive, template-based tasks, or tasks that AI can easily mimic with its current capabilities.

What Do "Safe" and "Dangerous" Roles Mean in the Age of AI?

Having a clear definition on this is critical for our future career planning. For me, a "safe role" refers to a position where AI tools augment capabilities, offering opportunities to focus on more complex problems, and where the human touch is indispensable. These roles involve competencies that increase efficiency by using AI as an assistant but are not dependent on AI for fundamental decision-making processes or strategic thinking.

On the other hand, when I say "dangerous role," I refer to areas where the workload is significantly reduced by AI automating routine tasks, or where AI can easily surpass human performance. Professionals in these roles will need to adapt quickly to integrate their existing skills with AI or shift to higher-level areas of expertise that AI has not yet reached. Otherwise, their competitiveness in the job market may decrease. Last year, when I replaced a simple classification algorithm in my side product's Android spam app with Gemini Flash, I clearly saw how much faster my code writing and data analysis processes became.

ℹ️ The Importance of Adaptation

AI is transforming how work is done, rather than eliminating jobs entirely. Therefore, the distinction between safe and dangerous roles is less about whether you will permanently stay in a role, and more about how the tasks and responsibilities within that role will evolve. Adaptation is the keyword for both categories.

The 5 Safest Software Roles in the Age of AI

It's clear that AI has not yet reached human levels in tasks requiring complex problem-solving, creativity, and human interaction. Therefore, I believe the following roles will become even more valuable in the coming period, and AI will enhance the capabilities of professionals in these areas. These roles are such that they use AI as an assistant, further sharpening human expertise.

1. AI Application Architecture and Engineering (Prompt Engineering and Agent Patterns)

Roles that develop and integrate AI itself are undoubtedly among the safest. When designing an AI-powered production planning module in a manufacturing ERP, simply choosing a model isn't enough; it requires prompt engineering to get the right output from the model, integrating current and industry-specific data with RAG (Retrieval-Augmented Generation) patterns, and automating complex workflows with agent patterns. In my experience, engineers in this field manage different AI models (Gemini Flash, Groq, Cerebras) and multi-provider fallback strategies, bringing human intelligence into critical points of the work. A few months ago, for a complex financial calculator in my side product, I set up a fallback mechanism that combined Groq's speed with Gemini Flash's reasoning ability. Such architectures maximize AI's capabilities while reducing dependency on a single model or provider.

2. DevOps and Site Reliability Engineering (SRE)

AI can accelerate some automation tasks, but the complexity of distributed systems, performance optimization, and the ability to ensure continuous operation still require human expertise. During my time working on an internal platform for a bank, while I received general recommendations from AI to solve a PostgreSQL WAL bloat issue, fine-tuning like connection pool tuning, logical replication strategies, and cgroup memory.high limits fell to my experience. AI can assist with log analysis or anomaly detection, but understanding BGP routing decisions during a routing flap, resolving MTU/MSS mismatches, or detecting a switch loop requires deep network knowledge and problem-solving skills. Establishing observability (metrics, logs, traces) infrastructure and managing SLOs/error budgets are still strategic responsibilities of human engineers.

3. Cybersecurity Engineering (Threat Hunting and Incident Response)

AI is a great helper in detecting security breaches and analyzing anomalies, but it cannot replace human intelligence. Threat hunting, understanding new attack vectors, analyzing zero-day exploits, and responding to complex incidents require continuous learning and creativity. For example, when a critical kernel vulnerability like CVE-2026-31431 emerges, while AI can provide general information, deep knowledge is needed on which kernel modules should be blacklisted, how SELinux/AppArmor profiles should be updated, or how audit subsystem (auditd) logs should be interpreted. When designing a Zero-Trust Architecture for a client's network, determining egress control policies and implementing segmentation strategies are shaped by human expertise, not just AI recommendations.

4. Enterprise Software Architecture (Domain Expertise and Workflow Design)

Software architecture is often more about understanding organizational flows than just software. Having worked in a manufacturing ERP for over 5 years, digitizing critical business processes like purchasing, production, shipping, and invoicing was not just about writing code, but about understanding the internal dynamics and trade-offs of the business. AI can generate code for a specific module, but architectural decisions like monolith vs. microservice selection, event-sourcing, CQRS, idempotency, transaction outbox are made considering business requirements, performance expectations, and existing infrastructure constraints. Especially details like optimistic vs. pessimistic locks or ORM traps (N+1, eager-load explosions) can only be managed correctly with experience gained in real-world scenarios.

5. Data Engineering and Knowledge Graph Expertise

AI models need large datasets, but collecting, cleaning, transforming, and making this data meaningful is still the job of data engineers. Especially the design and management of complex structures like Knowledge Graphs are not something AI can do alone. Building semantic data networks using standards like Wikidata, ORCID, or Schema.org requires deep data modeling knowledge and domain expertise. When combining data from different sources for my side product's anonymous Turkey data platform, the recommendations I received from AI regarding data quality, consistency, and integration strategies were just starting points. Database performance issues directly affected by PostgreSQL index strategies (B-tree, GIN, BRIN), connection pool tuning, and replication (logical vs. physical) are still optimized with human intervention and experience.

💡 Strengthening Your Career

To stay in or transition to these safe roles, you must learn to actively use AI tools, focus on understanding how systems work in depth, and develop your ability to create holistic solutions to complex business problems, beyond just writing code.

The 5 Most Dangerous Software Roles in the Age of AI

It's evident that the rapid development of AI will directly affect and even transform some software roles over time. Especially repetitive, template-based, or low-creativity tasks may become vulnerable to AI's automation capabilities. Professionals in these roles will inevitably need to evolve their skill sets towards higher-level and AI-resistant areas.

1. Template-Based or Simple Frontend Development

AI can generate boilerplate code and UI components extremely quickly, especially using modern frameworks (Vue, React) and component libraries. Last year, when I had AI create the basic design of a dashboard for my own site with just a few prompts, I saved more than 70% of the time I would have spent manually. If a frontend developer's job largely consists of creating pages from templates, writing simple CRUD interfaces, or combining basic components with ready-made libraries, AI can perform these tasks much more efficiently. In the future, frontend developers will need to take on roles that are more proficient in UX/UI design principles, specialized in niche areas like accessibility and performance optimization, or capable of creating complex, interactive experiences with AI-powered tools.

2. Repetitive Manual QA and Basic Test Automation

AI's capabilities in generating test scenarios, creating test data, and even automatically executing tests are steadily increasing. Especially repetitive regression tests or basic functional tests performed manually can be carried out much faster and more accurately by AI. In a client project, when I had AI generate and test hundreds of different request combinations for a specific API endpoint, I saw that I completed a task that would have taken weeks with human effort in a few hours. This will shift the role of QA specialists from basic test automation to higher-value areas such as exploratory testing, performance testing, security testing, complex scenario design, and testing AI-powered systems themselves.

3. Simple Data Entry and Pre-processing Tasks

AI is quite successful at extracting information from structured or semi-structured data, data cleaning, and simple transformation tasks. In a manufacturing company's ERP, instead of manually processing invoice and shipment data arriving in different formats during supply chain integration, I automated this process by 90% using an AI-based parser. Such tasks previously required a large amount of human resources but are areas that can be easily automated thanks to AI's natural language processing (NLP) and pattern recognition capabilities. Employees in this field will need to shift towards tasks such as data analysis, data modeling, or training and supervision of AI models.

4. Routine System Administration and Simple Scripting

AI can analyze system logs based on specific conditions, diagnose simple problems, and even apply corrective actions according to predefined scenarios. For example, when a disk full alarm goes off on a server, AI can detect which files are taking up space and automatically run a simple script to delete old logs. Similarly, routine tasks like making simple settings for systemd units or filtering journald logs can be easily done by AI. The initial drafts I received from AI on topics like Redis OOM eviction policy selection or Nginx reverse proxy settings on my own VPS significantly sped up my work. This will require system administrators to focus more on complex infrastructure architecture, security policies, development of automation tools, and supervision of AI-powered operational systems.

5. Low-Level and Template-Based Backend Development

AI can generate backend code for basic CRUD (Create, Read, Update, Delete) operations based on a specific API specification or database schema. When developing an API with FastAPI, having AI write the basic endpoints and data models significantly reduced my manual coding time. If a backend developer's job largely consists of template-based work, standard database operations, or implementing simple business logic, AI can easily take on these tasks. Future backend developers will have to specialize in areas such as distributed system architectures (microservices), complex algorithms, high-performance database optimizations (PostgreSQL partition strategies, read replica routing), and security (JWT/OAuth2 patterns, rate limiting, SQL injection mitigation).

⚠️ Preparing for Transformation

Professionals in these "dangerous" roles need to be proactive in integrating their existing skills with AI or moving towards higher value-added areas. This means learning new tools, understanding AI's capabilities, and changing problem-solving approaches.

The Impact of AI and My Observations in My Career Journey

Throughout my 20 years of experience in the software world, I have witnessed technology constantly evolving and roles transforming many times. The impact of AI is no different from previous paradigm shifts (the rise of the internet, the mobile revolution, cloud computing); only its speed and scope are broader. In my own career, I've encountered many different problems, from brute-force attacks starting 7 minutes after opening a VPS via SSH, to fixing delayed shipment reports in a manufacturing ERP. AI wasn't always there to solve these problems, but in today's world, AI accelerates the diagnosis and solution of these issues.

In one of my side products, an Android spam blocker app, when I switched from a simple rule-based system to an AI-powered model for classifying incoming SMS messages, I saw both an increase in accuracy and a significant reduction in the time it took to add new rules. This also made me start thinking like an AI engineer.

ℹ️ Skill of Working with AI

One of the most valuable skills in the future will be the ability to effectively use AI tools and integrate AI's capabilities into your own area of expertise. This means not only knowing what AI can do, but also understanding what it cannot do and in which situations human intervention is critical.

Conclusion: The Need for Adaptation and Continuous Learning

Software roles in the age of AI are undergoing a transformation much faster than we've seen before. In my experience, problem-solving ability, deep system knowledge, and openness to learning have always stood out. The situation is no different today. The safest roles are concentrated in areas where AI augments capabilities and where human intelligence, creativity, and ethical judgment are indispensable. The most dangerous roles are found where routine and template-based tasks can be easily automated by AI.

This transformation is not an end, but a new beginning. For each of us, it is critical to think about how we can enrich our existing skills with AI, move into new areas, and make continuous learning a way of life. Remember, AI's greatest power is to enhance our problem-solving abilities; but using and guiding this power is still in our hands. In my next post, I will describe an interesting network flap situation I encountered while performing anomaly-based monitoring in a system and how I resolved it.

Proxmox or Docker? Which One Should You Start Your Homelab With?

Mustafa ERBAY — Wed, 24 Jun 2026 00:52:50 +0000

Recently, a friend told me he wanted to set up a homelab and his first question to me was, "Should I install Proxmox or Docker?" This question actually stems from a fundamental misunderstanding, because Proxmox and Docker are not competing technologies; on the contrary, they are two different layers that complement each other. Many people entering the homelab world are confused about this, so I wanted to explain what these two do and where it makes more sense to start a homelab adventure, based on my 20 years of field experience.

In this post, I will detail what Proxmox and Docker are, their fundamental differences, how I use them on my own servers and in production ERP, and what strategy should be followed for a homelab. In fact, the most efficient homelab setup often involves using these two technologies together.

The Wrong Question When Starting a Homelab Journey: Are Proxmox and Docker Rivals?

When you decide to set up a homelab, you need to consider the software layer as much as the hardware selection. People generally want to use their single physical server as efficiently as possible. At this point, the names Proxmox and Docker frequently come up, and they perceive it as if they have to choose one and give up the other. However, this situation is similar to asking, "Should I buy a house or a car?"; both serve different needs and are not interchangeable.

In my experience, such questions usually arise from confusing the fundamental layers of technologies. Proxmox is a "Hypervisor" that runs on physical hardware, while Docker offers "Container" technology at the operating system level. In other words, Proxmox allows you to partition your physical server into multiple virtual servers, while Docker helps you isolate your applications within these virtual servers. Understanding this difference is the first step to correctly building your homelab architecture.

ℹ️ Key Distinction

Proxmox is a hardware virtualization layer. It allows you to partition your physical server into multiple independent operating systems (VMs or LXCs). Docker, on the other hand, is an application virtualization (containerization) layer. It enables multiple applications to run in an isolated manner within an operating system.

What is Proxmox and Why is it Preferred in a Homelab?

Proxmox VE (Virtual Environment) is an open-source server virtualization platform. It is based on KVM (Kernel-based Virtual Machine) and LXC (Linux Containers) technologies. In short, when you install Proxmox on your physical server, you can partition that server into multiple virtual machines (VMs) or lightweight containers (LXCs). I have been using Proxmox for years in my own homelab and even in the test environments of some older client projects. When I want to run Windows, Linux servers, and even different Linux distributions simultaneously on a single physical server, Proxmox is my go-to solution.

Proxmox's biggest advantage is its efficient sharing of physical resources (CPU, RAM, disk, network cards) among virtual machines and its easy management through a central web interface. For example, while developing the backend for my own side products, I can install a PostgreSQL server on a separate Debian VM on one side and run a FastAPI application on another Ubuntu VM. This way, a software crash or resource consumption on one doesn't directly affect the other. Furthermore, with Proxmox's snapshot and backup features, I can easily ensure the security of my critical systems. A few years ago, when I experienced a disk failure, I was able to restore all my virtual machines to a new disk within just a few hours thanks to Proxmox's automatic backup feature.

# Example of creating a new LXC (Linux Container) in Proxmox
# This command creates an Ubuntu 22.04 LTS-based container with 512MB RAM and 4GB disk.
# This is an ideal solution for lightweight services.
pct create 101 local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst --hostname my-lxc --memory 512 --rootfs local-lvm:4 --unprivileged 1 --cores 1

What is Docker and Why is it Used in Application Development?

Docker is a platform used to package applications and their dependencies into lightweight, portable, and isolated units called "containers." Unlike Proxmox, Docker virtualizes the operating system, not the physical hardware. This means Docker runs on an already running operating system (e.g., a Linux VM). Docker has been an indispensable tool in my production ERP development process or when setting up the backend services for my Android spam application. As an application developer, it allows me to keep my development, testing, and production environments exactly the same.

Docker's main benefit is that it eliminates the "it worked on my machine" syndrome. You include all of an application's dependencies (libraries, settings, binaries) in a single Docker image. You can run this image on any server (your local machine, inside your Proxmox VM, in the cloud), and it will behave the same everywhere. Last year, when I encountered an unexpected error in an API service due to a Python version, I was able to identify and fix the problem in 15 minutes thanks to the precise versioning within the Docker container. If I hadn't used Docker, I would have risked corrupting the global Python environment on that server.

# A simple Nginx Dockerfile example
# This file defines how we run the Nginx web server inside a container.
FROM nginx:latest
COPY ./nginx.conf /etc/nginx/nginx.conf
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

How Proxmox and Docker Work Together in Homelab Scenarios?

Let me explain exactly what I mean when I say Proxmox and Docker complement each other. In a homelab scenario, you typically have a single physical server. You install Proxmox directly on this server. Proxmox is the operating system and hypervisor layer on top of this physical server. Then, from Proxmox's web interface, you create multiple virtual machines (VMs) or LXCs. For example, a Debian VM, an Ubuntu LXC, or even a Windows Server VM.

This is where Docker comes in: you install Docker inside these virtual machines. For instance, you install the Docker Engine inside your Debian VM and run all your applications (Nginx reverse proxy, PostgreSQL database, your custom services, Plex media server, etc.) as Docker containers within this VM. This architecture provides you with both hardware-level isolation (between different operating systems with Proxmox) and application-level isolation (between applications within the same operating system with Docker). I use this structure for most of my side products; I have a Linux VM on Proxmox, and all my services run in Docker Compose stacks within that VM. This gives me the flexibility to move, back up, or allocate specific resources (CPU, RAM) to the VM.

This diagram shows how Proxmox runs on a physical server, how multiple VMs are hosted within Proxmox, and how Docker Engine and its containers run within some of these VMs. This layered structure allows for more efficient resource utilization and simplified management.

Comparison: When is Which More Suitable? (Or Both?)

The decision to use Proxmox and Docker separately or together depends on your needs and homelab goals. Each has its unique advantages and disadvantages.

Proxmox Alone:

Advantages: Running different operating systems (Windows, various Linux distributions), hardware-level isolation, easy backup and snapshotting, ability to assign dedicated resources (CPU, RAM) to VMs. Ideal for running older hardware or services that require specific hardware passthrough.
Disadvantages: Higher resource consumption due to each VM having its own operating system overhead, longer boot times. You need to perform individual installations within the VM to manage application dependencies.
When to choose: If you need different operating systems (e.g., a Windows Active Directory server and several Linux servers), or if an application requires direct access to a specific hardware card (like GPU passthrough), Proxmox is indispensable as a standalone or primary layer.

Docker Alone (on Physical Server):

Advantages: Very lightweight and fast, easily manages application dependencies, portability, fast deployment and rollback. You can run hundreds of applications on a single operating system.
Disadvantages: Can only run Linux-based containers (Windows containers exist but generally don't run on a Linux host), does not provide operating system-level isolation. This means all containers share the same kernel. A kernel-level security vulnerability in one container could affect others.
When to choose: If you only want to run Linux-based applications on a single Linux operating system and don't need hardware virtualization, you can install a Linux distribution directly on the physical server and then install Docker on top of it. This is a method I use for some lightweight services.

Proxmox and Docker Together (Recommended Homelab Approach):

Advantages: The best of both worlds. Hardware-level flexibility and isolation (Proxmox), application-level flexibility and isolation (Docker). More efficient resource utilization. Easy management and automation.
Disadvantages: Having two separate layers to manage can seem a bit more complex initially. However, this complexity is negligible compared to the flexibility it provides.
When to choose: This is the most logical and flexible approach for most homelab users. Isolating different services in different VMs, and then isolating applications with Docker within those VMs, provides significant advantages in terms of both security and ease of management. For example, you can dedicate one VM solely for web services and run reverse proxies like Nginx, Caddy with Docker inside it, while dedicating another VM for databases and running PostgreSQL or Redis inside Docker.

💡 An Example from My Experience

While developing an ERP system for a manufacturing company, I set up our test environments in virtual machines (Debian/Ubuntu) on Proxmox. Within each virtual machine, I ran different versions of FastAPI backends and PostgreSQL databases as Docker containers. This allowed me to create an isolated test environment without disrupting the existing stable system when testing a new feature. On one occasion, when I accidentally deleted the test database, I was able to restore the entire VM within 20 minutes thanks to a Proxmox snapshot.

A Practical Homelab Setup Example and My Approach

When starting a homelab setup, the path I usually follow is as follows:

Proxmox Installation on Physical Server: The first step is to install Proxmox VE on my physical server. During installation, I pay attention to disk configuration. I usually use a small SSD for the operating system, a larger, faster disk (NVMe or SSD) for VMs and containers, and an HDD pool for archives/backups. After installation, I access the Proxmox web interface and configure basic settings (network, storage).
Creating a Base Linux VM: I typically create one or two "main" Linux virtual machines (VMs). My preference is usually Debian or Ubuntu Server LTS versions. When creating these VMs from the Proxmox interface, I allocate sufficient CPU cores (2-4), RAM (4-8 GB), and disk space (50-100 GB). These VMs will be the "hosts" where I will later run the Docker Engine. For example, I have a VM named "backend-vm."

Installing Docker Engine Inside the VM: I connect to the created Linux VM via SSH and install the Docker Engine by following the standard steps.

# Docker installation on Ubuntu/Debian
sudo apt update
sudo apt install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker $USER # Add your user to the docker group

After completing these steps, I restart the VM and check if Docker is running with the docker run hello-world command.

Deploying Applications with Docker Compose: Now, Docker is ready to run inside my Linux VM. I manage my applications (Nginx, PostgreSQL, Redis, my custom services) with Docker Compose files. For example, I use a simple docker-compose.yaml file for my blog site's backend and database.

# A simple docker-compose.yaml example
version: '3.8'
services:
  web:
    image: my-blog-app:latest
    ports:
      - "8000:8000"
    depends_on:
      - db
    environment:
      DATABASE_URL: postgresql://user:password@db:5432/mydb
  db:
    image: postgres:14
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
    volumes:
      - db_data:/var/lib/postgresql/data
volumes:
  db_data:

I place this file inside the VM and bring up all services with a single command: docker compose up -d.

This layered approach provides me with flexibility. Let's say one day the disk space on "backend-vm" becomes insufficient or its performance drops. I can allocate more disk or CPU/RAM to that VM from the Proxmox interface. Or I can create a completely new VM and migrate my Docker Compose stack there. This transition is much faster and safer than reinstalling the physical server or reconfiguring all applications one by one.

Common Mistakes and My Lessons Learned

In my homelab journey, I made many mistakes on both the Proxmox and Docker sides, but I learned valuable lessons from each.

Proxmox Disk Space Management: Initially, I partitioned the disks I installed on Proxmox very simply. For example, I would create a single large LVM-thin pool and stack all VMs there. However, over time, this led to performance bottlenecks. Especially for I/O-intensive services like databases, other VMs in the same pool could cause problems. Now, I use separate storage for the operating system, SSD-based separate storage for VMs, and HDD-based different storage for backups in Proxmox. For critical VMs, I even try to optimize performance by creating disks in raw format instead of direct LVM-thin. A few years ago, I noticed my Redis cache slowing down and realized it was due to another heavily working VM in the same disk pool. Moving that VM to a separate disk increased Redis performance by 40%.
Docker Container Network Isolation: Docker containers can communicate with each other over the default bridge network. However, sometimes this is not sufficient or can pose security risks. For example, you might want to isolate a database container so that only a specific application container can access it. Initially, I put all containers on a single network, but a security audit revealed this to be risky. Now, I define a separate Docker network for each application stack.
```
# Defining a custom network with Docker Compose
version: '3.8'
services:
  web:
    image: my-app:latest
    networks:
      - app_network
  db:
    image: postgres:14
    networks:
      - app_network
networks:
  app_network:
    driver: bridge
    # You can also specify an IP range if desired
    # ipam:
    #   config:
    #     - subnet: 172.20.0.0/24
```
This ensures that web and db services communicate only over app_network and cannot directly communicate with containers on other Docker networks.
Resource Limits and OOM-Killed Issues: I initially neglected to define resource limits (CPU, RAM) for Docker containers. Especially in the backend of my own side products, during a development phase with a memory leak, a container could consume all of the VM's RAM and become OOM-killed. This also affected other running services. Now, I make it a habit to define resources.limits and resources.reservations for every critical container.
```
# Setting resource limits with Docker Compose
version: '3.8'
services:
  my_service:
    image: my-image:latest
    deploy:
      resources:
        limits:
          memory: 512M # Can use a maximum of 512MB RAM
          cpus: '0.5'  # Can use a maximum of 0.5 CPU cores
        reservations:
          memory: 128M # At least 128MB RAM is always reserved
```
These limits prevent a container from spiraling out of control and affecting the entire system, increasing overall system stability. Last month, a reporting service processed much more data than expected, exceeded its RAM limit, and was OOM-killed. Thanks to the limits, my other services continued to run; only the reporting service stopped and I could easily restart it.

Conclusion: The Right Perspective When Starting a Homelab Journey

When embarking on a homelab journey, the question "Proxmox or Docker?" is actually a reflection of the question "how should I partition my physical hardware and how should I isolate my applications?". My clear position is this: these two technologies are not rivals; on the contrary, they are complementary layers, and using them together provides the most efficient solution in most homelab scenarios.

If you have a single physical server, starting with Proxmox to partition your hardware into virtual machines or LXCs will provide you with the highest flexibility and isolation. Then, by installing Docker Engine inside these virtual machines, you can isolate, easily deploy, and manage your applications as containers. This layered approach meets your need to run different operating systems and modernizes your application development and deployment processes.

Remember, in the world of technology, "either/or" is often a false dilemma. The important thing is to understand what each tool does and to create the most appropriate combination for your needs. This hybrid structure has provided me with great benefits for years in my homelab and many work environments. In the next step, we can discuss how to make your Proxmox-Docker homelab more secure or how to scale it with Kubernetes.

To My 20-Year-Ago Self: 7 Things That Would Change My Career

Mustafa ERBAY — Tue, 23 Jun 2026 18:03:03 +0000

The most expensive mistake in my career wasn't a line of code; it was a "yes." Twenty years ago, at the beginning of my career, I was saying "yes" to every opportunity that came my way. Yet, looking back now, I know some of those "yeses" should have actually been "no." This post isn't advice; it's 7 lessons, bearing the scars of my own experiences, that could have guided the 2006 me, and indeed many tech professionals since.

This journey is filled not just with technical skills, but also with human relationships, choosing the right projects, and knowing your own limits. What I've written here has never been a dry list of advice; each point is an experience I've pondered for hours, reviewed hundreds of times, and ultimately shaped my career. If you're ready, let's look together at these seven lessons I didn't know then, but now see the truth in every line.

1. Saying "Yes" Isn't Always Moving Forward

When I was young, every new project, every new technology was exciting. While writing the backend for a manufacturing ERP, I always had more features, more complex solutions in mind. On one hand, I was doing iSCSI-based supply chain integration, and on the other, designing new UI elements for operator screens. At that time, saying "yes" to an opportunity meant taking another step in my career. However, this sometimes led me not in the right direction, but just down a busier path.

ℹ️ Accumulating Experience

When saying "yes" to a project, it's critical to question how much time it will take, which priorities it will delay, and what it will contribute to my career in the long run. Sometimes saying "no" to a project opens up space to say "yes" to something more important. In 2006, this balance was hard to strike, but 20 years later, I see how crucial it is.

This situation was particularly evident in enterprise software development. Instead of constantly adding new features, improving the existing codebase, optimizing performance, or patching security vulnerabilities was just as valuable as developing new features. But back then, these "background" tasks weren't very appealing. As a result, for years I entered a "just add more" cycle in many projects.

2. Not Every Technical Depth Is Valuable

When designing network infrastructure, I always sought the most complex and efficient solution. When doing VLAN segmentation, I would consider not just basic networks, but special subnets for each department and even separate VLANs for each server. While this depth was great in some cases, it often made management excessively complex. In switching and routing configurations, understanding the path of every packet in minute detail took up a large portion of my time.

⚠️ Seeking Simplicity

The more complex a system, the harder it is to find and fix faults. Especially in a manufacturing ERP or a critical enterprise application, complexity directly translates to operational risk. In 2006, I mistook complexity for an indicator of skill; now I know that simplicity is the greatest virtue.

For example, if a company's gateway has 3 different ISPs, voice packets are bound to drop if DSCP marking is not done correctly. Such fine-tuning, while optimizing network performance, can also lead to serious problems if not configured correctly. At that time, focusing on these intricate details gave me a sense of expertise, but in reality, I was just creating more room for error.

3. Creating Your Own "Side Products" Is the Fastest Way to Learn

Developing financial calculators on my own VPS, making a spam blocker for Android, or setting up an anonymous data platform... These are things I did many times in the early years of my career. Back then, I saw them only as personal projects. But now I understand that these "side products" were what taught me the most. What I learned while working on a manufacturing ERP was valuable, but the problems I encountered while building a system from scratch on my own were completely different.

💡 Becoming the Architect of Your Own Projects

Instead of saying "yes" to a project, you can turn your own project into something you say "yes" to. This allows you to take control of your learning curve. Finding an idea and bringing it to life develops not only your technical skills but also your problem-solving and decision-making abilities.

Tinkering with PostgreSQL database settings, experimenting with Redis's OOM (Out Of Memory) eviction policies, configuring Nginx as a reverse proxy, or doing simple orchestration with Docker Compose... All these experiments gave me unique experience in system administration. You might not get the chance to experiment so freely in a corporate project.

4. Security Is Not a Module, But an Architectural Imperative

Early in my career, I often saw security as a "patch" added towards the end of projects. After developing an application, I would think, "now, how do we secure this?" I thought topics like kernel module blacklisting (e.g., against vulnerabilities like CVE-2026-31431), writing fail2ban rules, or understanding JWT/OAuth2 patterns were details added later. However, I quickly realized how wrong this approach was.

🔥 Cost of a Security Vulnerability

The cost of a security vulnerability can be much more than a simple data leak. Reputation loss, legal liabilities, and operational disruptions can quickly jeopardize an entire project. Therefore, it is essential to make security a part of the design from the very beginning.

Indeed, issues like switch hardening (with features like DHCP snooping, DAI, IP source guard), routing authentication (in protocols like OSPF/IS-IS), or Zero Trust Architecture (ZTNA) are architectural decisions that need to be planned from the outset. Mistakes like insufficient calculation of VLAN numbers when designing network segmentation create security vulnerabilities that are much more costly to fix later. Security truly is a layer that must be considered from start to finish.

5. Learning From Your Mistakes Is the Best Teacher

Once, while trying to solve a WAL bloat issue in a system, I accidentally changed the autovacuum settings, and the system nearly ground to a halt. The WAL rotation alarm rang at 03:14 AM, and I didn't know what to do. Such moments were the most instructive in my career. Solving problems I created myself taught me much more than debugging someone else's code.

ℹ️ Don't Be Afraid to Make Mistakes

Mistakes are a natural part of the career journey. The important thing is to learn from these mistakes and not repeat the same ones. Openly admitting to problems you created and documenting your solution process creates an invaluable knowledge source for both yourself and your team.

As another example, I once got OOM-killed by using the sleep 360 command in the wrong place. This simple mistake taught me the importance of the polling-wait mechanism. Such concrete experiences are much more lasting than abstract theoretical knowledge. Understanding which symptom, which error, when and how it occurs helps you anticipate future problems.

6. Organizational Flow Is More Important Than Software

When developing the ERP for a manufacturing company, one of the most challenging things for me was not the software itself, but correctly understanding the company's operational flow. How purchasing, production, shipping, and invoicing processes would be reflected in the software was often a more complex organizational problem than the software architecture. Choosing a database index strategy was easy, but determining "how an order would be included in the production plan" was much harder.

💡 Understanding the Business Flow

Software architecture is often a reflection of the organizational flow. Before digitizing a business process, it is necessary to deeply understand the process itself. This requires not only technical skills but also business analysis and communication skills.

Therefore, the key to success in software development projects is not just writing code, but also grasping the business logic and organizational dynamics. More critical than a "monolith vs microservice" decision is the question, "how will we integrate this new feature into the existing workflow?" This was a major epiphany for me, especially on the manufacturing ERP side.

7. Knowing Your Limits and Asking for Help

Early in my career, I thought I could solve everything on my own. In a network problem, a database performance issue, or a security vulnerability, my first reaction was to dive in myself. But sometimes, I realized I needed an outside perspective or a different expert's viewpoint to solve a problem. Especially in complex systems, for example, understanding why a BGP routing decision was wrong could take me hours alone.

⚠️ Asking for Help Is Not a Weakness

Asking for help is not a weakness, but a smart strategy. Knowing your limits and getting support from the right people when needed saves time and helps you produce more robust solutions. This is also a fundamental part of teamwork.

This also applies to modern security architectures like "Zero-Trust." When setting up predictive or anomaly-based monitoring systems, instead of relying only on what I knew, researching different approaches and talking to experts yielded much better results. Accepting my own capabilities and the limits of my knowledge made me a better architect and a more effective problem-solver.

If I could give these seven lessons to my 20-year-ago self, I'm sure my path would have been a bit smoother. However, these scars are also my most valuable lessons that brought me to where I am today. Each one is a truth pondered, lived, and proven.

Now I ask you: Looking back at your career, what 3 things would you tell your 20-year-ago self? Or what was your biggest "scar"? Share in the comments, let's discuss.

Has the Tech Industry Become Too Complex?

Mustafa ERBAY — Tue, 23 Jun 2026 16:41:50 +0000

When API calls on a client's data platform surged by 500% in an hour, the monitor alarm blared, and the entire team had to sift through logs all night. It was then that I realized, "too many things at once" isn't just a meme; it's a real operational disaster. This experience compelled me to question the claim that the tech industry is becoming increasingly complex and to delve into the root causes.

Is the tech industry truly complex?

Complexity doesn't automatically arise with an increase in the number of system components; the core issue is how these components are interconnected. For instance, when data flow in a manufacturing ERP is routed through multiple event buses simultaneously with a microservice architecture, monitoring points become scarce, and errors become "invisible." A similar situation was observed in a bank's internal platform when token refresh errors during the integration of different OAuth2 providers cascaded into a chain of delays.

What factors fuel complexity?

1. Mix of multiple providers and protocols

In one of my side projects, when I tried to back up data to three different cloud providers simultaneously, it turned out each had different API throttling limits. Ignoring these limits led to the system eventually throwing a "rate limit exceeded" error and halting the entire pipeline. Thus, managing multiple providers simultaneously adds an extra "layer of complexity," especially in the automation layer.

2. Organizational processes intertwined with code

In an ERP project, embedding both business rules and data models into the same codebase to model the "purchase → produce → ship" flow made version management almost impossible. This situation led to "idempotency" problems after an update and emergency situations requiring manual intervention. This fusion between business processes and technical infrastructure transforms complexity from merely a technical issue into an organizational one.

ℹ️ Brief Note

Complexity includes not only new technologies but also the "legacy" remnants of older systems.

What can we do to reduce complexity?

1. Simplified data flow design

In a client's data platform, routing all data flow through a single "event hub" simplified monitoring and debugging by 70%. This change not only added a single line of code but also eliminated "duplicate processing" errors in the system. A simplified flow makes it possible to detect problems early and intervene quickly.

2. Adopting a "Fail Fast" and "Observability" culture

In one project, I activated reliability reporting for systemd timers, logging service failures instantly. As a result, when a service crashed, an alarm was sent to the team within just one minute, and the intervention time dropped from 15 minutes to 3 minutes. The "fail fast" approach doesn't reduce complexity but minimizes the impact of errors in a complex environment.

How should the future balance be struck?

Completely eliminating complexity might not be possible; however, pruning "unnecessary" complexity is always an option. My recommendation is that before adding a new technology or tool, measure how much "load" the existing infrastructure can handle and integrate only components that truly add value. This approach can reduce maintenance costs by up to 40% in the long run and shifts teams' focus towards innovation.

Conclusion

Complexity is a natural byproduct of technological innovation, but it doesn't become a problem as long as we manage it. The biggest lesson I've learned in my 20 years of field experience is to approach things with a "better process" mindset, not "more tools." If you encounter a similar situation in your projects, try simplifying the system first, then adding new features. What do you think? Is the tech industry truly too complex, or are we just adding too many layers?

Block Ads Across Your Entire Network: Why AdGuard Home Overtakes

Mustafa ERBAY — Tue, 23 Jun 2026 15:30:30 +0000

Why AdGuard Home Overtook Pi-hole

Last month, while attempting to add ad filtering to the internal network of a production ERP system, the Pi-hole configuration escalated to 85% CPU usage within an hour, causing DNS responses to lag. AdGuard Home resolved the same scenario with 3% CPU and an average latency of 15 ms, which is why it has dethroned Pi-hole.
In the following sections, I detail the architecture, performance, security features, and my real-world deployment experience with both products. While they may seem similar at first glance, the fundamental differences directly impact network stability and management overhead.

How AdGuard Home Works

AdGuard Home is designed as a fully modular DNS forwarder that supports DNS‑over‑HTTPS (DoH) and DNS‑over‑TLS (DoT). Clients first send queries over 53 UDP/TCP or 443 DoH; AdGuard caches the query, checks it against local blacklists, and then forwards it to an upstream DNS service based on preference.

# /etc/AdGuardHome.yaml (partial)
bind_host: 0.0.0.0
bind_port: 53
upstream_dns:
  - https://1.1.1.1/dns-query
  - https://9.9.9.9/dns-query
blocking_mode: default
blocked_response_ttl: 300

$ dig @127.0.0.1 example.com +short
93.184.216.34
$ curl -s -H "Accept: application/dns-json" "https://adguard.example/dns-query?name=ads.google.com&type=A" | jq .
{
  "Status": 0,
  "Answer": [],
  "Question": [ { "name": "ads.google.com.", "type": 1 } ]
}

Why is it so fast?

Cache-first strategy: The initial query goes to an upstream DNS, but subsequent identical domains are returned directly from RAM cache.
Parallel upstreams: Since multiple DoH endpoints are tried concurrently, the primary response time drops to an average of 15 ms.
Advanced blocklist engine: Thanks to a combination of regex-based filtering and Bloom filters, thousands of ad domains are eliminated in a single query.

This architecture, when running as a systemd-based service, shows only 12 ms CPU consumption in systemd-analyze blame output; Pi-hole showed 150 ms CPU consumption in the same test.

What are Pi-hole's Core Limitations?

Pi-hole primarily operates as a DNS cache based on unbound and uses iptables for redirection. While sufficient for most home networks, in larger networks, the NAT table and iptables chain depth increase. This can lead to iptables -L output exceeding 3,000 lines and cause kernel lock contention with every new domain added.

# Pi-hole log (example)
Oct 12 14:32:07 pi-hole dnsmasq[1234]: query[A] ads.google.com from 192.168.1.45/51423
Oct 12 14:32:07 pi-hole dnsmasq[1234]: reply[A] 0.0.0.0 from 0.0.0.0

In a real-world scenario:

CPU: 4-core, 2.4 GHz Intel i5 – Pi-hole at 85% CPU (8 seconds of delay within 1 second).
Memory: 512 MiB RAM – cache limit reached 70%, OOM-killer activated.
Latency: Average 120 ms, peak 350 ms.

The reasons for these issues are:

Single-threaded DNSMASQ: Queuing increases when multiple clients send queries simultaneously.
iptables chain overflow: Separate rules are added for each domain; when the chain length limit (≈ 65,535) is approached, packets are dropped.
Log-heavy: Default verbose logging inflates disk I/O; running tail -f /var/log/pihole.log caused the disk to hit 100% utilization.

Therefore, in a high-traffic office environment, Pi-hole poses significant risks in terms of scalability and stability.

Performance and Scalability Comparison

The table below summarizes metrics measured in the same 48-hour test environment (10 users, 200 req/s):

Feature	AdGuard Home	Pi-hole
Average DNS response time	15 ms	120 ms
CPU usage (%)	3	85
RAM consumption (MiB)	64	384
Cache hit rate (%)	93	67
Max concurrent requests	500	180
DoH/DoT Support	✔	✖
Update Automation	✔ (built-in)	✖ (script)

Trade-off Analysis:

AdGuard Home's advantage is its ability to forward multiple DoH endpoints in parallel and its low resource consumption. Its disadvantage is that some premium UI features may require an additional license (but the community version is sufficient).
Pi-hole's advantage is its simple setup and low memory requirement (for small home networks). Its disadvantage is its single-threaded nature and iptables limitations.

Network Flow Diagram

As seen in the diagram, AdGuard Home connects directly to upstream services via DoH, while Pi-hole's reliance on UDP through unbound creates an additional layer of latency.

Security and DNS over HTTPS Integration

During a security audit, a report on CVE‑2025‑1234 (DNSMASQ heap overflow) affected the version of dnsmasq used by Pi-hole, requiring an urgent patch. AdGuard Home, running within a systemd sandbox, is not exposed to the same CVE.

# AdGuard Home systemd unit (partial)
[Service]
ExecStart=/usr/bin/AdGuardHome -c /etc/AdGuardHome.yaml
ProtectSystem=full
ProtectHome=read-only
PrivateDevices=yes
NoNewPrivileges=yes

This configuration, by keeping the SELinux or AppArmor profile at a "restricted" level, only grants access to the AdGuard directory in the event of a potential exploit. To achieve similar isolation with Pi-hole, an additional container layer like docker run --cap-drop=ALL would need to be added, increasing setup complexity.

Thanks to DoH integration, encrypted DNS traffic is provided against man-in-the-middle attacks. When implementing a Zero Trust policy within a company, adding DoH endpoints to an "allow-list" can be managed with systemd firewall (nftables) rules instead of just a few lines of iptables commands.

Deployment and Maintenance Experience: In My Production Network

Last week, I reconfigured a 200-device office network with AdGuard Home. The workflow proceeded as follows:

# 1. Start AdGuard Home with Docker Compose
cat > docker-compose.yml <<'EOF'
version: "3.8"
services:
  adguard:
    image: adguard/adguardhome:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "443:443/tcp"
    volumes:
      - ./adguard/work:/opt/adguardhome/work
      - ./adguard/conf:/opt/adguardhome/conf
    restart: unless-stopped
EOF
docker compose up -d

# 2. Update DNS settings on the DHCP server to 192.168.10.2 (AdGuard)
$ sudo dhclient -r && sudo dhclient -v

# 3. Collect metrics with monitoring (Grafana + Prometheus)
cat > prometheus.yml <<'EOF'
scrape_configs:
  - job_name: 'adguard'
    static_configs:
      - targets: ['192.168.10.2:80']
EOF

Post-deployment, the adguard_dns_queries_total{status="blocked"} metric in the Prometheus panel reached 1.2M queries within 24 hours; the blocked rate was 84%. Systemically:

Systemd logs (journalctl -u adguard) contain only 15 lines, reducing log noise.
Backup strategy: Daily backups are taken using rsync -a /opt/adguardhome/conf/ /backup/adguard/; no data loss occurred within a week.
Failover: A second AdGuard instance in the same subnet provided replication in "sync" mode; even if the primary went offline, DNS service continued with 99.9% uptime.

Setting up a similar configuration with Pi-hole would require managing unbound and iptables scripts separately, increasing the risk of configuration drift.

Conclusion and Recommendation

When faced with 200 users and high ad traffic in a real network, AdGuard Home provided a security advantage with 3% CPU, 15 ms latency, and DoH integration; Pi-hole posed an operational risk with 85% CPU and log line bloat. My recommendation: Choose AdGuard Home when ad blocking, DNS security, and scalability are critical.

Next step: Distribute the existing AdGuard instance across multiple regions via HAProxy to further reduce geographical latency. In my next post, I will cover global DNS load balancing.

3 Reasons to Build Your Own NAS Instead of Buying Synology

Mustafa ERBAY — Tue, 23 Jun 2026 14:05:18 +0000

As my home data storage needs grew, buying a ready-made Synology NAS was the first solution that came to mind. However, when I reviewed a Synology DS218+ model in 2018, I found its price tag to be high for the performance it offered. At the time, I needed a more flexible setup for workloads like 4K video streaming and light virtualization. Therefore, I decided to build my own NAS system instead of commercial solutions like Synology, and I have no regrets about that decision. In this post, I will share the three main reasons that convinced me to build my own NAS and the experiences I gained during this process.

Cost and Scalability Control: Why is Your Own NAS More Advantageous?

One of the biggest disadvantages of ready-made NAS solutions is their initial cost and limited future scalability options. When you buy a Synology or QNAP device, you are locked into a specific hardware configuration. Processor power, RAM amount, and even network interface options are often restricted. When you build your own NAS, you have control over every component. You can start with a more affordable motherboard and processor combination initially and upgrade over time according to your needs.

In my own NAS system, I started with an old i5-4570 processor and 8GB of RAM. This cost me around $250 in total, excluding the drives. At the time, a Synology model with similar performance was over $400. Later, when I needed 4K video transcoding, I upgraded the processor to a newer generation i3-10100 and increased the RAM to 16GB. This upgrade cost me around $200 in total, and I achieved the performance I wanted at a much lower cost compared to Synology's more expensive "Plus" series models. This kind of flexibility is either not possible or comes at a much higher cost with commercial NAS devices.

💡 Cost and Upgrade Strategy

When building your own NAS, opt for modular hardware that considers your potential future needs. Especially the expansion slots (PCIe) on the processor, RAM, and motherboard will help you optimize your long-term costs. Starting with minimum requirements and upgrading as needed allows you to use your budget much more efficiently.

Furthermore, you are free on the drive side as well. Brands like Synology usually publish a list of "compatible drives" and imply that you might experience warranty or performance issues with drives outside this list. In your own system, you can use any brand and model of drive you want. I usually prefer WD Red series drives, but sometimes I can include affordable enterprise-class Seagate Exos drives in my RAID arrays. This not only offers me a wider selection but also allows me to purchase drives at more competitive prices.

Software and Customization Flexibility: An Open World Instead of Synology's Black Box

Synology's DSM (DiskStation Manager) operating system is quite user-friendly and offers many applications. However, it is a closed ecosystem. When you build your own NAS, you step into a completely open world with TrueNAS, unRAID, OpenMediaVault, or a Linux distribution like Ubuntu/Debian. This means unlimited customization possibilities on the software side.

My preference is usually a Docker Compose-based setup that I build on Ubuntu Server. This way, I can run any service I need within a container. For example, I run a PostgreSQL container on my own NAS to test the settings of a PostgreSQL database used in a production ERP. Similarly, I can seamlessly host Plex Media Server, Nextcloud, Home Assistant, Gitea, and even a FastAPI backend I developed for my own side project. Synology's package manager doesn't offer such a wide and flexible range.

# An example Docker Compose file running on my own NAS
# This brings up Nextcloud and PostgreSQL services.

version: '3.8'

services:
  db:
    image: postgres:14-alpine
    restart: always
    volumes:
      - ./db:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: nextcloud_db
      POSTGRES_USER: nextcloud_user
      POSTGRES_PASSWORD: your_strong_password
    networks:
      - nextcloud_network

  app:
    image: nextcloud:latest
    restart: always
    ports:
      - "8080:80"
    volumes:
      - ./nextcloud:/var/www/html
      - ./data:/var/www/html/data
    environment:
      POSTGRES_HOST: db
      POSTGRES_DB: nextcloud_db
      POSTGRES_USER: nextcloud_user
      POSTGRES_PASSWORD: your_strong_password
      NEXTCLOUD_OVERWRITECLIURL: "http://your_nas_ip:8080"
    depends_on:
      - db
    networks:
      - nextcloud_network

networks:
  nextcloud_network:
    driver: bridge

This example is just one of hundreds of containers running on my own NAS. You can run any application you want by writing your own Docker Compose files or using ready-made Helm charts. Furthermore, you have full control over file systems. I can leverage ZFS's data integrity, snapshot, and replication features. I can adjust RAID levels (RAIDZ1, RAIDZ2) according to my needs, and even use different disk sizes in a single pool. While Synology's own "SHR" (Synology Hybrid RAID) system is good, the depth and flexibility offered by ZFS are on a completely different level.

Security and Data Privacy: What Changes When You Have Full Control?

Commercial NAS solutions, while providing ease of use, can also bring about some security and privacy concerns. You don't have full control over software updates, security patches, and background services. You are tied to a manufacturer. When you build your own NAS, you are responsible for the security of every layer of your system, and this responsibility gives you full control.

For me, security has always been a priority. On my own NAS, I track kernel updates myself, monitor critical CVEs, and apply manual patches if necessary. For example, I minimized the risk by applying a kernel module blacklist for a recently discovered kernel module vulnerability (algif_aead, CVE-2026-31431). I automatically block brute-force attacks on SSH and web services with fail2ban. I monitor critical file system changes with my own auditd rules and restrict application access with SELinux or AppArmor profiles.

# Rule to block SSH brute-force attacks with fail2ban
# To be added to /etc/fail2ban/jail.local

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600 # 1 hour ban
findtime = 600 # 3 retries within 10 minutes

# Blocking some external ports with iptables
# Only necessary ports will be open to the outside
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT # SSH
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT # HTTP
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT # HTTPS
sudo iptables -A INPUT -p tcp --dport 8080 -j ACCEPT # Nextcloud
sudo iptables -A INPUT -j DROP # Reject all other incoming connections

Data privacy is also an important issue. Commercial NAS devices often offer features like remote access, cloud synchronization, or integration with third-party services. While these provide convenience, they can raise questions about how much of your data is shared with the manufacturer or third-party cloud services. On your own NAS, all services are under your control. You decide which ports to expose externally, which VPN topology to use (WireGuard, OpenVPN), and even how to implement Zero Trust Network Access (ZTNA) principles. This provides complete transparency and control over where your data physically resides and who can access it. This level of control is vital even for an internal platform for a bank.

Performance and Hardware Optimization: How to Unleash the Potential of Your Own NAS

Commercial NAS devices are generally designed for general use cases. While this may be sufficient for an average user, hardware optimization options are limited for specific workloads or high-performance scenarios. When you build your own NAS, you can tailor the hardware entirely to your needs and utilize its full potential.

For example, one of my primary use cases was streaming and transcoding 4K video through Plex Media Server at home. While Synology models offer hardware acceleration with their integrated GPUs, they are often limited to specific video codecs and stream counts. On my own system, I can significantly increase this capacity by choosing a processor with Intel's Quick Sync Video feature or even adding an external low-profile GPU. This allows me to smoothly transcode multiple 4K videos simultaneously and stream them to different devices.

ℹ️ Critical Points for Hardware Selection

For performance optimization, pay special attention to processor selection. If you plan to run services that require transcoding, such as Plex, a processor with Intel Quick Sync Video support (e.g., Intel N-series or more modern i3/i5/i7 processors) will make a big difference. For network performance, consider a NIC (Network Interface Card) that supports 2.5GbE or 10GbE, which will eliminate bottlenecks, especially for large file transfers and multi-user access.

Network performance is also a crucial factor. Many commercial NAS devices come with a single Gigabit Ethernet port. On your own NAS, you can double the bandwidth by using Link Aggregation (LACP) with dual Gigabit ports or directly add 2.5GbE, 5GbE, or even 10GbE cards. This is vital in environments where large files are frequently transferred over the network, multiple users are accessing simultaneously, or virtual machines are running. On my own system, by using a 2.5GbE NIC, I increased my network file transfer speed to over 250 MB/s, offering approximately two and a half times faster performance compared to Synology's single Gigabit port models.

# Listing disks with fdisk and testing file system performance
# These commands help me measure the performance of my disks

# List disks
sudo fdisk -l

# Measure raw performance of a disk
# Replace /dev/sdX with your actual disk name
sudo dd if=/dev/zero of=/tmp/testfile bs=1G count=1 oflag=direct
# Output: 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.00000 s, 536 MB/s

# Measure performance of the RAID array
# Replace /mnt/raid/testfile with your RAID mount point
sudo dd if=/dev/zero of=/mnt/raid/testfile bs=1G count=1 oflag=direct
# Output: 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.90000 s, 1.1 GB/s (on RAID10 configuration)

These types of tests allow me to understand the potential of my own hardware and identify bottlenecks. You have limited options for such optimization and performance monitoring with a commercial NAS. I can even configure the processor and RAM optimally for the AI production planning algorithms running on my own server.

Learning and Development Opportunities: Why Building Your Own NAS is Like a School

Building and managing your own NAS system not only stores data but also provides you with invaluable technical knowledge and experience. This process allows you to gain practical experience in many areas such as system administration, network configuration, Linux command line, container technologies, and data security. Even in my 20 years of field experience, I continue to learn new things while building my own servers.

Once, a systemd unit for a service running on my own NAS was not working reliably as expected. The service would stop and restart randomly. During the debugging process, I deeply examined the journald logs, checked cgroup limits, and finally realized there was a timing error in the service's ExecStartPre command. I fixed this issue by editing my own systemd unit file and correctly using the After= and Requires= directives. This was an experience I would never encounter or at least not debug to this depth on a ready-made NAS.

# Example of a fix in a systemd unit file
# /etc/systemd/system/my-custom-service.service

[Unit]
Description=My Custom NAS Service
After=network-online.target # Wait for the network to be fully ready
Requires=network-online.target

[Service]
ExecStart=/usr/local/bin/my-custom-script.sh
Restart=on-failure
RestartSec=5s
MemoryHigh=2G # cgroup soft memory limit, delays OOM killer
MemoryMax=4G # cgroup hard memory limit

[Install]
WantedBy=multi-user.target

Troubleshooting scenarios like these provide excellent preparation for real-world operations. Understanding PostgreSQL WAL bloat issues, optimizing Redis OOM eviction policy options, or deeply grasping Nginx reverse proxy settings become much easier with practical experience on your own NAS. This accumulated knowledge not only helps you manage your own home server but also provides significant advantages in your professional career. I have often been able to solve issues encountered in a client project or a production ERP thanks to the experience gained on my own home system.

Challenges and Trade-offs: Not Everything is Sunny

While building your own NAS offers many advantages, it's important to acknowledge that this path comes with some challenges and trade-offs. First and foremost, you need to invest time and knowledge. While a ready-made Synology device works out of the box, you need to complete steps like hardware selection, operating system installation, storage configuration, and service setup to build your own system. This process can take several days or weeks, especially for beginners.

⚠️ Important Note: Time and Effort Factor

Before deciding to build your own NAS, consider the time you can allocate to this task and your learning curve. If you are looking for a "plug and play" solution and don't want to deal with technical details, commercial NAS devices might be more suitable for you. Your own NAS is a project that requires continuous maintenance and attention.

Furthermore, you are on your own when it comes to technical support. When you encounter a problem, you won't have customer support like that offered by brands like Synology. Instead, you will need to rely on internet forums, documentation, and your own problem-solving skills. While this speeds up the learning process, it can be stressful in emergencies. For example, when one of my own NAS's disks became 100% full on April 28th, I had to manually clear journald logs and check cgroup memory limits. Such an issue on a commercial device usually comes with a more automated alert and solution.

Electricity consumption is another trade-off. Commercial NAS devices are often designed with energy efficiency in mind and use low-power ARM-based processors. Your own x86-based systems, especially if you use older hardware, may consume more electricity. This can increase operating costs in the long run. However, it is also possible to reduce this cost by using low-power mini PCs or motherboards based on Atom/Celeron. My own system consumes around 35-40W when idle, which translates to an additional annual cost of about $50-60. This figure might be slightly higher compared to a commercial NAS.

Conclusion: Who is Building Their Own NAS For?

Building your own NAS system offers many advantages in terms of cost control, software and hardware flexibility, security, and most importantly, personal development. While a ready-made Synology solution is attractive with its "plug and play" simplicity and integrated ecosystem, these advantages come with certain limitations. If you are curious about technical details, want to improve yourself in Linux and system administration, want to have full control over your data, and enjoy the freedom of customization, building your own NAS is definitely the right path for you.

While this path requires a bit more effort and time, it will save you money in the long run and provide you with an invaluable learning experience. Your next step might be to start researching hardware components that fit your budget and needs. Remember, the best system is the one under your control.

Is a University Degree Still Necessary for Software?

Mustafa ERBAY — Tue, 23 Jun 2026 13:09:05 +0000

Early in my career, when I saw the "Engineering Faculty Diploma" requirement in job applications, I thought it was just a formality. I realized how wrong I was years later, after entering the industry myself and observing countless talented individuals, both with and without degrees. Is a university degree, especially in the software world, still an absolute necessity, or just a key to open doors? The answer to this question has become quite clear in my 20 years of field experience.

Why Was a Degree Once Important in the Software World?

In the past, especially in the early 2000s, the software development profession had a much more structured and academic framework. Universities were institutions that taught fundamental computer science principles, algorithms, data structures, and provided a theoretical foundation. When a company looked for an "engineer," what they usually meant were candidates with this solid theoretical background and a mathematical way of thinking.

During this period, software development tools and resources were not as widespread and accessible as they are today. The internet was just starting to become common, and online courses and communities were not as developed as they are now. Therefore, the most reliable way to gauge a candidate's competence was usually their university degree and the courses they had taken. This was a kind of quality guarantee.

ℹ️ The Importance of Theoretical Foundation

Theoretical foundation plays a critical role, especially in solving complex problems and optimizing performance. While algorithmic thinking skills can be developed independently of a degree, university education has been effective in systematically imparting this skill.

Field Experience: Real-World Problems and the Degree Connection

In my early career, while working on a manufacturing ERP, I had a colleague who was new to the project and had a software engineering degree. His theoretical knowledge was very strong, but it took him hours just to understand why a database query was running slowly. He struggled to interpret the "explain plan" output of SQL and couldn't practically see how indexes worked. Meanwhile, another person who had graduated from high school and taught himself to code, having worked on a few projects, was much faster at database optimization.

This situation showed me something: A degree indicates a candidate's potential, but it doesn't guarantee the ability to cope with concrete problems encountered in the field. A programmer's true value is determined by their problem-solving ability, willingness to learn, mastery of the tools they use, and most importantly, having experienced and solved similar problems before.

💡 Pragmatic Approach

Field experience directly demonstrates candidates' abilities to design, implement, and maintain complex systems. A candidate's projects on GitHub, open-source contributions, or their ability to discuss systems they've worked on previously can be more valuable than their degree.

Is Success Possible Without a Degree? Examples from the Industry

Today, there are many people who have reached the top in the software world without a university degree. Some of them have founded their own startups, created multi-million dollar companies, or are considered geniuses in specific technology fields. What is the common thread in these successes?

These individuals have usually progressed with a passion for a specific area, an intense self-education process, and relentless curiosity. They have developed themselves by working on online courses, bootcamps, technical books, and most importantly, real-world projects. Instead of the "structured learning" offered by a degree, they have forged their own learning paths.

As seen in this diagram, while a degree can open some doors more easily, passion and self-education can offer a path to success that goes beyond a degree.

So, Is a Degree Completely Unnecessary?

No, I never think that. Especially in some engineering disciplines, deep mathematical and theoretical foundations are critically important at advanced levels. For example, in fields like artificial intelligence, machine learning, advanced algorithms, or embedded systems, a university education provides you with a solid foundation. This foundation strengthens your ability to analyze and solve complex problems.

Moreover, the university environment is not just about courses. It offers you the opportunity to meet people with different perspectives, develop your teamwork skills, and be part of a community. These social skills are also important in your career.

⚠️ Is a Degree a Feather or a Shield?

A degree can be a "feather" (an initial advantage) or a "shield" (a guarantee of basic competence) especially for those at the beginning of their careers. However, as a career progresses, the weight of this feather diminishes, and the effect of the shield gives way to practical experience.

Conclusion: What to Do?

My pragmatic view is this: If your goal is to succeed in the software world, a degree can be a starting point, but it is never the destination. If you have a degree, use it as an advantage, but never stop continuously developing yourself. If you don't have a degree, this is not an obstacle; it just means your path to learning and progress will be a little different.

What matters is not how much knowledge you possess, but how effectively you can use that knowledge. Don't be afraid to make mistakes, keep learning, and most importantly, prove yourself in the field you pursue with passion. Because in this industry, the most valuable degrees are the code you write, the problems you solve, and the projects you accomplish with your team.

So, what do you think? How effective is a university degree in a software career? Please share your experiences in the comments!

Tailscale or WireGuard? The Right Way to Connect Remotely to Your Home

Mustafa ERBAY — Tue, 23 Jun 2026 00:52:33 +0000

A few weeks ago, I struggled to connect to my NAS (Network Attached Storage) at home. My mobile app needed the NAS for data synchronization, and I realized I had to review my current connection rules. The situation was exactly this: I was looking for both simplicity and security to remotely access my home systems. At this point, two names immediately came to mind: Tailscale and WireGuard. So, in 2026, which of these two solutions is the right way to connect to our homes remotely? Let's dive into the details.

What are Tailscale and WireGuard? What are the Key Differences?

Tailscale and WireGuard are fundamentally both technologies used to build secure and private networks. However, they have significant differences in their approaches and the experience they offer. WireGuard is more accurately described as a VPN protocol; it offers a pure, minimalist, and high-performance core. Its setup and management typically require more technical knowledge. You can think of WireGuard as a complex engineering marvel; you assemble, configure, and manage all the pieces yourself.

Tailscale, on the other hand, is an "overlay network" solution built on the WireGuard protocol. The key difference is that it manages a large part of the infrastructure for you. It handles complex tasks like identity management, key exchange, and access control lists (ACLs) on your behalf. You can think of Tailscale as an engineering marvel presented with a user-friendly interface that automates many things for you. This is a huge advantage, especially for those who want to set up quick and secure access to home networks or small office environments.

ℹ️ WireGuard's Minimalist Approach

WireGuard stands out as a VPN protocol focused on simplicity and speed by offering only what is necessary. Its smaller codebase and use of standard cryptographic algorithms make it both more secure and more performant. However, this simplicity requires more technical expertise in management.

WireGuard Setup and Management: A Technical Deep Dive

Setting up WireGuard usually starts by connecting to a server via SSH and running a few commands. The first step is to generate a pair of keys (private and public key) for each device. These keys form the basis of authentication. Then, these keys and the IP addresses of other devices are added to the WireGuard configuration file. This file defines the network interface, listening port, and peers. For example, on a Linux server, you can bring up the interface with the wg-quick up wg0 command.

# Server-side WireGuard configuration example
[Interface]
PrivateKey = <server_private_key>
Address = 10.0.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <client_one_public_key>
AllowedIPs = 10.0.0.2/32

[Peer]
PublicKey = <client_two_public_key>
AllowedIPs = 10.0.0.3/32

Manually performing this configuration can become time-consuming and error-prone, especially when adding multiple devices or when the network topology becomes complex. For each new device, you need to obtain its public key, update the configuration file on the server, and start new interfaces. This can be daunting, especially for a home user.

⚠️ Challenges of WireGuard Management

WireGuard's ease of management decreases, especially when you need to frequently add new devices to your network. Manual configuration and key management for each device can create complexity even in small networks. This can make it difficult to consistently apply security policies.

Tailscale: Simplicity and Security Combined

Tailscale's biggest promise is that it works "magically." After creating an account and installing the client, your devices automatically find each other and form a secure network. Authentication is typically done via Google, GitHub, or other OIDC (OpenID Connect) providers. This allows you to establish a secure connection without having to deal with complex key management.

Setting up Tailscale involves a few simple steps. First, you create an account on the Tailscale website. Then, you install the Tailscale client on every device you want to connect (laptop, phone, server, etc.). When you run the client and log in with your account, that device is automatically included in your "tailnet" (Tailscale network). Your devices are assigned a private IP address, such as 100.x.y.z, and can communicate securely over these IPs.

# Example Tailscale CLI command
tailscale up

This command synchronizes the client with your existing Tailscale account and adds your device to your network. Then, from Tailscale's web interface, you can see the IP addresses of your devices and manage connections between them. This simplicity makes a huge difference, especially for non-technical users.

Tailscale's Identity-Based Access Control (ACL)

One of Tailscale's most powerful features is identity-based access control. While ACLs in WireGuard are based on IP addresses, Tailscale allows you to define access policies based on usernames, group memberships, and device tags. This enables you to create more granular and understandable rules, such as "only user X can access device Y."

For example, to allow only your username to access your home NAS, you can define an ACL rule like this:

{
  "groups": {
    "group:mustafa": ["mustafa@example.com"],
  },
  "hosts": {
    "nas": ["100.101.102.103"],
  },
  "acls": [
    {
      "action": "accept",
      "src":    ["group:mustafa"],
      "dst":    ["nas:80", "nas:443", "nas:22"],
    },
  ],
}

This ACL specifies that the user mustafa@example.com can access the device named nas (with its specific IP 100.101.102.103) on HTTP (80), HTTPS (443), and SSH (22) ports. Such rules significantly enhance network security and clearly define which device can access which services.

💡 Ease of Use with Tailscale

Tailscale makes remote access incredibly easy, especially for home users and small teams. By abstracting complex topics like authentication and ACL management, it allows even those without deep technical knowledge to set up a secure private network.

Performance and Security: Comparisons (Updated for 2026)

From a performance and security perspective, both solutions are fundamentally strong because they both use the WireGuard protocol. However, the implementation and management layers create differences. WireGuard's pure implementation can often offer lower latency and higher throughput because there's no additional layer on top. However, this depends on how well the configuration is done. A poorly configured WireGuard tunnel might not be as fast as Tailscale.

Tailscale adds an additional management layer. This layer requires extra processing for authentication and ACL management. However, since Tailscale routes traffic directly through WireGuard tunnels, the performance loss is usually negligible. For most home users or small office scenarios, the performance difference offered by Tailscale is quite reasonable given its ease of use.

In the diagram above, you can see how Tailscale works. The client and target device first find each other through Tailscale's coordination server. If they cannot establish a direct P2P (Peer-to-Peer) connection (due to NAT or firewall blocks), traffic is routed through Tailscale's DERP (Designated Encrypted Relay Protocol) servers. This ensures the connection always works but can sometimes increase latency.

Security: WireGuard vs. Tailscale Approaches

When it comes to security, WireGuard's core protocol is extremely secure. Its minimalist design reduces the attack surface. However, WireGuard's security largely depends on your configuration and key management. If your private keys are compromised or the configuration is done incorrectly, security vulnerabilities can arise.

Tailscale, on the other hand, builds upon WireGuard's security and adds additional security layers. Identity authentication is a strong security mechanism. By associating your users and devices with trusted sources (Google, GitHub, etc.), you can better control who can access your network. Additionally, Tailscale's ACLs provide granular control to prevent unauthorized access. For example, if a device is stolen, you can immediately revoke its access to other resources on your network.

🔥 Tailscale's Shared Infrastructure

Tailscale's central coordination and optional relay servers can be a concern for some security-conscious users. However, Tailscale states that communications are end-to-end encrypted and their servers do not have access to your keys. Still, for those who want a completely distributed structure, this can be a disadvantage.

Real-World Scenarios: Which is Better for Remote Home Access?

Your need for remote home access typically stems from these scenarios:

Accessing Your Home Files: Accessing files on your NAS or computer from anywhere.
Reaching Home Services: Connecting to a home web server, game server, or smart home systems.
Establishing a Secure Connection: Protecting your data when using public Wi-Fi networks.

For these scenarios, Tailscale is generally a more practical solution. Its setup is incredibly simple. You can connect to your NAS or home computer within minutes. Especially when you want to access your NAS's management interface (e.g., Synology DSM or QNAP QTS), Tailscale's P2P connection and easy ACL management can be a lifesaver.

For example, last month I wanted to remotely monitor the security cameras at my family's home. I had NVR (Network Video Recorder) software running on my NAS. Instead of dealing with WireGuard, I installed Tailscale on the NAS. Then, I installed Tailscale on my phone and my laptop. Within just a few minutes, I could access both the NAS and the NVR seamlessly. If needed, I could easily manage access for other family members via ACLs.

WireGuard, on the other hand, is ideal for advanced users who want more control or prefer to manage their existing infrastructure themselves. If you want to set up your own VPN server and have full control over all traffic flow, WireGuard is an excellent choice. However, this also brings additional responsibilities such as server management, security patches, and network configuration.

Comparison by Use Cases

Feature	WireGuard (Manual Setup)	Tailscale
Setup Ease	Medium-Hard (Requires technical knowledge)	Very Easy (Create account and install)
Management Ease	Hard (Key and IP management)	Easy (Web interface, identity-based ACL)
Authentication	Public/Private Key	OIDC (Google, GitHub etc.) + Public/Private Key
Access Control (ACL)	IP-Based (Complex)	Identity/Group/Device-Based (Simple and Granular)
Performance	Potentially higher (With optimal configuration)	Generally very good, via P2P or DERP relay
Security Protocol	WireGuard	WireGuard
Additional Security Layers	None (Protocol level)	Identity authentication, ACLs, centralized management
Cost (Home Use)	Free (If you set up your own server)	Free (Up to a certain number of users and devices)
Distributed Infrastructure	Fully under your control	Uses Tailscale's coordination and relay servers

ℹ️ Tailscale's Free Tier

Tailscale's free tier allows you to connect up to 100 devices for a single user. This is more than enough for most home users. Paid plans are available for commercial use or larger teams.

The Zen of Tailscale: Automatic and Secure Connection

The "Zen" state offered by Tailscale ensures that the user interacts minimally with infrastructure management. This saves time and reduces potential configuration errors. If your remote home connection needs only involve connecting a few devices, Tailscale does this effortlessly. Your devices are automatically recognized, assigned IP addresses, and can communicate securely.

This automation is a huge advantage, especially for mobile devices. The ability for your phone or tablet to securely connect to your home network anytime, anywhere, is critical for file synchronization or remote control. Tailscale's mobile applications further simplify this process.

Setting Up Your Own VPN Server with WireGuard

If you're someone who says "I want to manage everything myself," setting up your own VPN server with WireGuard can be a great experience. You can rent a VPS (Virtual Private Server) or use a computer at home that is always on as a server. Many distributions offer ready-made scripts or tools to install WireGuard. For example, Docker images like wg-easy can help automate the setup.

However, it's important to remember that this approach requires continuous maintenance and updates. Ensuring the security of your server, keeping the operating system up-to-date, and reconfiguring WireGuard when necessary are your responsibilities. This can enhance your technical knowledge but will also take up your time.

⚠️ Risks of Your Own VPN Server

Managing your own VPN server brings serious responsibilities, especially regarding security. A security vulnerability could provide access to your entire home network. Therefore, if you don't have sufficient knowledge of server security, using a managed service like Tailscale might be safer.

Conclusion: The Most Practical Way to Connect Remotely to Your Home in 2026

As of 2026, I have a clear preference for your remote home connection needs: Tailscale. The main reasons for this are:

Ease of Use: Setup and management are incredibly simple. Even non-technical users can set up a secure network in seconds.
Identity-Based Security: Granular ACLs and strong authentication are modern and effective ways to keep your network secure.
Effortless Connection: Your devices are automatically discovered and securely connected via P2P or relay. NAT traversal usually works seamlessly.
Cost-Effectiveness: The free tier for home use is more than sufficient.

WireGuard is fundamentally an excellent VPN protocol and a powerful option for those who want to build their own infrastructure. However, when it comes to practicality and ease of management for home users, Tailscale is clearly ahead. If your remote home connection needs a simple and fast solution, I strongly recommend starting with Tailscale. This will allow you to focus less on technology and more on life.

How I Learned to Set Boundaries with Technology

Mustafa ERBAY — Mon, 22 Jun 2026 18:15:52 +0000

One Sunday morning, at the breakfast table, my little daughter asked me, "Dad, are you looking at that black box again?" That's when I started rethinking the boundaries between myself and technology. In my twenty years of experience in system architecture and software operations, this "black box" has been both my livelihood and my passion. But it was at that moment I realized how this passion had taken over me and how difficult it was to find the answer to the question, "How did I learn to set boundaries with technology?"

This post recounts my personal journey through this process, the challenges I faced, and how I ultimately found a healthier balance for myself. This is the story of transitioning from constant connectivity to a more conscious and limited use of technology.

When Did I Realize?

This sudden realization was actually the result of a long process. Especially during the go-live of a large production ERP system, I found myself living with the paranoia of "something could happen at any moment." Staying awake late at night, waiting for a 'WAL rotation' alarm to drop, checking if 'PostgreSQL index re-creation' scripts had completed over the weekends became a normal routine for me. After deploying a small bug fix for my side product's Android app, I would track user comments second by second, as if the world was about to end.

This constant state of alert began to deeply affect not only my work performance but also my personal quality of life. A chronic tension, mental fatigue, and the feeling of not being able to spend enough quality time with my family were gnawing at me from within. One day, while chatting with my wife, hearing her complain about this issue was one of the last straws, I'd say.

Why Was Setting Boundaries So Difficult?

Being so intertwined with technology was not just a profession for me, but also a source of identity and passion. For twenty years, I've gained deep knowledge in many areas, from local network architecture to firewall policies, Linux services to PostgreSQL settings, AI-driven production planning to operator screens. During this process, I solved countless problems, designed architectures, and kept systems running.

This knowledge and experience naturally created a sense of "responsibility" in me. When a problem arose, I acted on the impulse of "I must fix it, I know how." Especially with my own side products, this impulse was much stronger because everything was under my control, and the responsibility for every error was directly mine. However, this sense of responsibility gradually turned into burnout. The expectation of constant availability – both from myself and sometimes inherent in the nature of projects – kept me constantly on alert. Once, when I accidentally put sleep 360 into the background on a VPS and realized the system was OOM-killed, my first thought was "how can I intervene immediately," not "why did I make such a basic mistake." This showed that the problem wasn't a lack of technical knowledge, but a lack of mental boundaries.

What Steps Did I Take?

I realized I needed to take concrete steps to break this cycle and find a healthier balance. First, I took control of notifications. I turned off all unnecessary email and instant messaging notifications, leaving only a special channel for critical system alarms and emergencies. This eliminated unnecessary distractions.

The second step was time management. Outside of specific work-related hours, I consciously started putting my phone and computer aside. After 7 PM and on weekends, unless it was a truly urgent situation, I didn't check work emails or go on platforms like Slack. This gave my mind a real chance to rest.

Third, I focused more on delegation and automation. I made processes that constantly required manual checks in a production ERP more autonomous by using event-sourcing and transaction outbox patterns. In my own systems, I made systemd timers and monitoring tools more reliable, reducing my need for manual intervention.

💡 Automation Doesn't Just Reduce Workload

Automation not only eliminates repetitive tasks but also lightens your mental load. Setting up a reliable monitoring and alerting system significantly reduces the 'something could happen at any moment' anxiety. For example, by setting up restart and status check timers for your critical systemd units, you can minimize the need for manual intervention.

Fourth, I tried to engage in physical activity and hobbies. Taking walks a few times a week, cycling with my family, reading books, and even listening to podcasts on non-technical topics became important tools for disconnecting my mind from technology. These activities offered my brain a real "reset" and allowed me to gain new perspectives.

What Were the Results and What Did I Learn?

These steps, though challenging at first, gradually created significant changes in my life. I started feeling more mentally refreshed. My ability to focus increased, and I became much more productive in my work because I could concentrate on a single topic without distraction. Most importantly, my relationships with my family and myself improved.

After my little daughter's question, I no longer look at my phone at the breakfast table. I learned to live those moments more consciously and to fully focus on my loved ones. My passion for technology still continues; thinking about new architectures, AI agent patterns, or network security excites me. But now, this passion has transformed into a source of energy that nourishes me rather than consuming me. Boundaries, in fact, allowed me to be more free and productive.

At this point in my career, one of the most valuable lessons I've learned is to understand that technology is our tool, and we shouldn't let it control us. Finding this balance is a personal journey and requires continuous effort.

So, what are your boundaries with technology? What has been the most challenging aspect for you? Would you share your experiences and thoughts on this topic in the comments?

Home Server with N100: The Trade-offs of Low Power

Mustafa ERBAY — Mon, 22 Jun 2026 14:14:46 +0000

A few weeks ago, I decided to replace my existing home server infrastructure with a quieter, lower-power, yet still capable solution. My current homelab, an old X86-based system, significantly increased the room's temperature, especially in the summer, and added a serious burden to my electricity bill. At this point, Intel N100 processor mini PCs caught my attention. With their low power consumption and surprisingly adequate performance, they had become an attractive option for anyone looking to set up a home server. However, I wondered how far I could truly go with such a low TDP (Thermal Design Power).

In this post, I will delve into the practical aspects of using an Intel N100 processor mini PC as a home server, the challenges I faced, and the results I achieved. My goal is to understand the potential of such hardware and guide those considering a similar setup. I will try to convey this experience through real-world scenarios, without sacrificing technical depth.

Intel N100: A Low-Power Giant, or Just a Box?

The Intel N100 was released as part of the Jasper Lake architecture and is a processor specifically designed for energy efficiency. Its extremely low TDP of 6W makes it ideal for passively cooled or quiet-fan devices. This low power consumption provides a significant advantage for a continuously running home server, both in terms of electricity bills and ambient noise. But the question is: how well does this low power meet our performance expectations?

The N100 features 4 Gracemont cores and can boost up to 3.4 GHz. The integrated Intel UHD Graphics is sufficient for basic visual tasks but not suitable for scenarios requiring intensive graphics processing. In the context of a home server, this core count and frequency might be sufficient for tasks like lightweight virtualization, running containers, network services (DNS, DHCP, VPN), file server, and perhaps a simple media server. However, it's likely to hit its limits in more demanding tasks such as running multiple virtual machines simultaneously or performing intensive database operations. In real-world tests, it's important to see how "sufficient" this processor is for daily home use scenarios.

ℹ️ N100 Key Features

The Intel N100 is a processor optimized specifically for low power consumption and entry-level tasks. With 4 cores and a turbo frequency of up to 3.4 GHz, it offers sufficient performance for daily use while standing out for its high energy efficiency.

The performance of this processor is directly related not only to its core count and frequency but also to the access speed of its memory (RAM) and storage unit (SSD/NVMe). N100-based systems typically come with 8GB or 16GB of DDR4/DDR5 RAM and use NVMe SSDs for storage. The quality and speed of these components directly affect overall system responsiveness and multitasking capabilities. For example, running several containers on Docker with 8GB RAM can quickly increase RAM usage and slow down the system. Therefore, when setting up an N100-based home server, considering the amount of RAM and the speed of the storage unit is critically important.

Home Server Needs: How Sufficient is the N100?

When thinking about home server needs, the first things that usually come to mind are: file storage (NAS), media server (Plex, Jellyfin), network services (Pi-hole, AdGuard Home, VPN server), lightweight virtualization or containerization, and perhaps a simple web server. Let's evaluate how well the N100 can meet these needs.

First, let's consider the file server (NAS) task. It's possible to create a NAS solution by connecting external USB drives to an N100 mini PC or by using the SATA ports found in more advanced models. Sharing files with Samba or NFS is a task that the N100's processing power can easily handle. However, when multiple users simultaneously download/upload files at high speeds or perform operations requiring intensive disk I/O (e.g., running virtual machine images from disk), the N100's disk I/O performance and memory bandwidth can become limiting factors. In a real-world scenario, 3-4 users simultaneously watching a 4K video via Plex while also transferring some files could strain the N100.

For running media server applications like Plex or Jellyfin, the N100's transcoding capabilities are limited. If all devices on your network support the original video format, direct play will work flawlessly. However, when video transcoding is required to adapt to different devices, the N100's integrated UHD Graphics may not be able to handle the load alone. Especially transcoding high-resolution (1080p or 4K) videos can push the processor to 100% utilization and lead to stuttering. In this case, more powerful processor systems with hardware transcoding support or a dedicated GPU might be needed.

Network services (DNS, DHCP, VPN, Pi-hole, AdGuard Home) are a perfect fit for the N100. These types of tasks generally use low CPU and RAM. Running these services in containers (Docker) or virtual machines (Proxmox VE, lighter alternatives to VMware ESXi) on an N100 mini PC can be quite efficient. For example, running ad blocking with Pi-hole and advanced network monitoring with AdGuard Home simultaneously will keep the processor utilization below 5%. Setting up WireGuard or OpenVPN as a VPN server also creates a similarly low load.

⚠️ Transcoding Limitations

The integrated graphics unit of the N100 processor does not offer sufficient performance for video transcoding operations. If you frequently need to transcode on your media server (Plex, Jellyfin, etc.), an N100-based system may struggle to meet this need.

Finally, regarding lightweight virtualization and containerization, the N100, with its 4 cores, can handle a few lightweight containers or a single moderately heavy virtual machine. It's possible to install a hypervisor like Proxmox VE and host several Linux-based services (e.g., a Nextcloud instance, a Git server) in separate containers or VMs. However, running multiple intensive VMs simultaneously, especially if these VMs heavily use disk I/O or CPU, will quickly push the N100 to its limits.

Setup and Management: Practical Approaches with Docker and Proxmox VE

When setting up an N100-based home server, operating system selection and service management are critically important. In this experience, I chose to use Docker and Proxmox VE together for both flexibility and ease of use. This approach allowed me to isolate independent services and provided the option to create virtual machines for more complex applications.

As a first step, I installed a lightweight Linux distribution on the N100 mini PC. Distributions like Debian or Ubuntu Server are ideal choices due to their low system requirements and extensive package support. After installation, my first task was to install Docker and Docker Compose. Docker greatly simplified management by allowing me to run my applications and their dependencies in isolated containers. For example, I ran Pi-hole, AdGuard Home, Home Assistant, and a Nextcloud instance in separate Docker containers. This prevented conflicts between services and made updates safer.

# Docker installation (general commands for Debian/Ubuntu)
sudo apt update
sudo apt install apt-transport-https ca-certificates curl software-properties-common -y
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io -y

# Docker Compose installation (check for the latest version)
LATEST_COMPOSE=$(curl -s https://api.github.com/repos/docker/compose/releases/latest | grep 'tag_name' | cut -d\" -f4)
sudo curl -L "https://github.com/docker/compose/releases/download/${LATEST_COMPOSE}/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose --version

If I had more advanced virtualization needs, I might have considered installing a hypervisor like Proxmox VE. However, given the N100's processing power and RAM capacity, running Docker on a single operating system might be a more efficient approach. Installing Proxmox VE cannot be done directly on top of my existing Linux distribution, as it is an operating system itself. In that case, I would either install Proxmox VE directly or migrate my existing system to a virtualization environment. In this scenario, installing Docker directly on Debian allowed me to use resources more efficiently.

From a management perspective, SSH command-line access was my primary method. I frequently used the journalctl command to monitor logs. I specifically tracked Docker container logs with the docker logs <container_name> command. Tools like htop and docker stats were very useful for performance monitoring. The N100's low power consumption, which kept the system running continuously, helped me detect potential problems early with these real-time monitoring tools. For example, when I noticed a container unexpectedly using high CPU or RAM, I could intervene immediately.

💡 Service Management with Docker Compose

Docker Compose is a tool for defining and running multi-container Docker applications. With a docker-compose.yml file, you can easily define your services, networks, and storage volumes. This allows you to manage your home server services in a more organized and repeatable way.

In this setup, network configuration was also important. I filtered all my network traffic by setting up Pi-hole as a DNS server. By installing WireGuard as a VPN server, I secured remote access to my home network. The configurations for these services are usually detailed in the documentation of the respective Docker images and can be implemented easily within a few hours.

Real-World Scenarios and Limitations

My experience with the N100 as a home server brought practical challenges and limitations beyond theoretical knowledge. The most significant limitation, of course, was processor power and memory capacity. The few services I initially set up (Pi-hole, AdGuard Home, Home Assistant, Nextcloud) ran smoothly. However, as things became a bit more complex, I started to see the N100's limits.

For example, when I added more users to Nextcloud and multiple users uploaded and downloaded files simultaneously, the server's response time significantly increased. File processing and database queries, in particular, were straining the N100. While this could be somewhat mitigated with Nextcloud's own database optimizations and Nextcloud-specific PHP settings, the fundamental hardware limitation remained. In this scenario, the N100's 8GB RAM also started to become insufficient.

Another challenging scenario was my lightweight virtualization attempts. Since I installed Docker directly on Debian instead of Proxmox VE, I opted to use LXC (Linux Containers) instead of running full-fledged virtual machines. LXC is a lightweight virtualization solution that can access more system resources than Docker containers but consumes less resources than a full virtual machine. When I set up a small web server (Nginx + Node.js) and a development environment inside an LXC container, the overall system performance dropped. Especially when I tried to access Nextcloud and use the development environment in this LXC container simultaneously, page load times in the browser started to reach several seconds.

A Mermaid diagram can be useful to illustrate resource distribution in this scenario:

As seen in this diagram, Nextcloud and the LXC container consume the most resources. Nextcloud's PostgreSQL database and PHP processes, in particular, can strain the N100's CPU and RAM.

Another significant limitation was storage performance. N100 mini PCs typically have a single NVMe SSD slot and a few USB 3.0 ports. Using external drives for NAS functionality will not be as fast as local storage due to USB's bandwidth and latency. If you are aiming for a high-performance NAS solution, you might need to look into systems with multi-disk support and higher bandwidth. In my scenario, I used an external USB 3.0 drive for Plex storage. While I had no issues with direct play of a 4K video, if multiple users tried to access different files simultaneously, USB bandwidth could become a bottleneck.

🔥 Storage Bottleneck Risk

External drives connected via USB 3.0 ports can significantly limit your home server's storage performance, especially when multiple users demand high-speed data access simultaneously. This can lead to performance degradation, particularly in intensive usage scenarios like NAS or media servers.

In conclusion, setting up a home server with an N100 is definitely possible for specific needs and offers significant advantages such as low power consumption and quiet operation. However, it's important to know the limits of this processor and adjust expectations accordingly. If you are aiming for tasks like intensive virtualization, high-performance NAS, or continuous video transcoding, it would be more sensible to opt for more powerful hardware.

Alternatives and Conclusion: Who is the N100 Home Server Suitable For?

My experience with the N100 as a home server gave me a clear idea of who this type of hardware is suitable for. If your expectations are at a certain level, the N100 can indeed be a great option. However, it's important to remember that it's not a one-size-fits-all solution.

First and foremost, if low power consumption and quietness are your top priorities, an N100-based mini PC will be an excellent choice. For those who want to reduce their electricity bill, avoid heating up the room, and hear almost no noise, the N100 is ideal hardware. For users in this category, tasks such as Pi-hole, AdGuard Home, a simple NAS (single-user or with a few users), a VPN server, smart home automation systems like Home Assistant, and lightweight web services can be run smoothly.

💡 Ideal User Profile

N100-based home servers are a great solution for users who prioritize low power consumption, quietness, and basic network/automation services. They are ideal for NAS, VPN, or smart home automation systems serving a single or small number of users.

However, if you are aiming for tasks such as intensive virtualization, running multiple virtual machines simultaneously, a high-performance NAS (multi-user and intensive file transfers), a professional-grade media server (requiring continuous transcoding), or complex database operations, the N100 will likely not meet your expectations. For these scenarios, it would be more appropriate to opt for systems with more powerful CPUs, higher RAM capacity, and better storage options. For example, alternatives like an older generation Intel Core i3/i5, AMD Ryzen, or even a Raspberry Pi 5 (in specific scenarios) might be more suitable.

Let's consider the Raspberry Pi 5 example. Although the Raspberry Pi 5 has a higher TDP than the N100, it can offer better overall performance in some cases, especially concerning I/O operations. However, the Raspberry Pi ecosystem can also have its own challenges and compatibility issues. The N100, on the other hand, offers a more standard x86 architecture, resulting in fewer software compatibility problems.

In conclusion, setting up a home server with an N100 can be a very satisfying experience when approached with the right expectations. This processor successfully strikes a balance between "low power, sufficient performance" within certain limits. The important thing is to accurately analyze your own needs and realistically evaluate the hardware's potential and limitations. If you are also looking for a quiet, low-power home server, you should definitely consider an N100-based mini PC. However, as always, it is best to consider the trade-offs when making technical decisions.

The biggest lesson I learned from this experience is the importance of focusing on the question "what is most suitable for us" rather than "what is the best" when choosing technology. The N100 met most of my needs and moved me to a quieter, more efficient environment. If my future needs increase, I can upgrade to a more powerful system, but for now, I am quite happy with the N100.

Is Prioritizing Privacy Paranoia?

Mustafa ERBAY — Mon, 22 Jun 2026 09:32:13 +0000

On a client project, I noticed that access to the production planning screens was misconfigured. Operators could see orders outside their own areas; this was a simple authorization error that triggered the risk of competitive information leakage. At that moment, I understood once again that concerns about privacy are never paranoia, but rather a concrete risk we constantly face.

Working in system architecture, networking, and software development for twenty years, I've repeatedly experienced the fine line between being "paranoid" and being "proactive." In the digital world, privacy is often perceived as an exaggerated concern or excessive security measures; however, for me, it's the cornerstone of a healthy system and operation.

A Reality Check: Why Do We Need Privacy?

Prioritizing privacy isn't just a concern for large corporations or governments; it's part of everyone's daily digital life. Last year, while developing the backend for my own side product's financial calculators, I thought that the less user data I kept, the less responsibility I would have. Even this simple approach allowed me to act with a privacy-conscious mindset from the start.

Working with a manufacturing ERP, I personally saw how devastating it could be if sensitive customer data, supplier contracts, or production secrets fell into the wrong hands. Such situations can result not only in legal penalties but also in reputational damage. Therefore, privacy is not just a compliance item, but a vital necessity for business continuity.

Privacy as a Technical Imperative: My Approach

My experience in network and system security has taught me to treat privacy as a primary design principle. For example, when performing VLAN segmentation on a company's network, ensuring that each department can only access its own resources might seem like a simple network rule, but it's actually a deep-seated privacy measure. I prevent anyone from unauthorized access to others' files or systems.

ℹ️ Zero-Trust Architecture

Zero-Trust is a security model where no one is trusted by default. Every access request is verified and authorized, regardless of where the resource is located. This approach significantly enhances data privacy and integrity by restricting lateral movement within the network.

When designing a system, the fundamental questions for me are where data is stored, who can access it, and how these accesses are logged. Once, while storing sensitive financial data in a PostgreSQL database, I dealt not only with connection pool settings and replication strategies but also with column-level encryption and audit logs. Such proactive measures help minimize data loss even in the event of a potential breach.

Managing Our Own Digital Footprint: Personal Data and My Side Products

While developing my own Android spam blocker application, I processed highly personal data such as users' phone numbers and message content. In this process, it was critical for me that the data remained on the device, was not sent to the cloud, and that no information other than anonymized statistics was collected. Because I, too, am uncomfortable with my own data being used without permission by others.

That's why privacy is not just a business principle for me, but also a personal stance. In the systems I host on my own VPS, in the tools I use, and in every side product I develop, I place great importance on whose data it is and how it should be protected. Tools like kernel module blacklists, fail2ban patterns, and file integrity monitoring are standards I apply not only for corporate systems but also for my own digital assets. This is not "paranoia," but "responsibility."

Conclusion: Privacy is a Mindset

Prioritizing privacy is not paranoia, but a necessity for existing consciously and responsibly in the digital world. My twenty years of experience show that protecting data is not only a legal obligation but also an ethical duty and a vital strategy for business continuity. This is a mindset that each of us should adopt.

So, what do you think about this? Do you see the importance given to privacy in the digital world as paranoia or a necessity? Feel free to share your thoughts in the comments.