Migrating from Proxmox to Debian 13: A Complete Home Server Build Guide
A homelab user ditches Proxmox for Debian 13, hand-building ZFS storage, Macvlan networking, and a Podman container stack.
A homelab enthusiast migrated from Proxmox VE to bare Debian 13 to gain deeper control and understanding of his home server. The build uses 4×128GB SSDs with BTRFS RAID 10 for root and a ZFS striped mirror pool for container data. Podman Macvlan gives each container its own LAN IP, with a kernel Macvlan shim resolving host-container isolation. Cockpit replaces the Proxmox web UI, complemented by Uptime Kuma, Ntopng, Technitium DNS, and WireGuard — all containerized with Podman for better security and rootless support.
Why Abandon Proxmox for Debian
In the world of virtualization and homelab setups, Proxmox VE is practically the gold standard for out-of-the-box solutions. It offers a polished web management interface, KVM virtual machine support, and LXC containers — giving enthusiasts a fast path to spinning up their own server environments. Yet that same "out-of-the-box" convenience can sometimes become a barrier to deeper learning.
A Reddit user shared his complete journey migrating from Proxmox to Debian 13. He openly admitted that his previous Proxmox setup was fairly basic and that he wasn't happy with how it was configured. That dissatisfaction pushed him to ask: could he use a more "bare" Linux distribution and build the entire system from the ground up, exactly the way he wanted — as a way to challenge himself and learn something new?
One detail worth highlighting: the user was clear that "I don't hate Proxmox, I just wanted a way to challenge myself." This mindset represents a significant segment of the homelab community — people who aren't just chasing a working result, but who want to understand and control every layer of their system.
Hardware and Storage Architecture
Host Hardware Specs
The migration was built on a host that's modest but more than capable:
- CPU: Intel Core i7-9700K
- RAM: 32GB DDR4-2666
- Storage: 4 × 128GB SATA SSDs
This configuration is more than enough to run multiple containerized services, and the four SSDs in particular provide the hardware foundation for a flexible storage array.
Partition and Filesystem Design
Rather than going with a simple partition scheme, this user carefully planned out his storage layout based on his specific needs — arguably the most impressive aspect of the entire migration. Here's what the layout looks like:
- 1GB EFI partition: for system boot
- 8GB SWAP (RAID 10): swap space
- 20GB root partition (BTRFS, RAID 10): core system files
- Remaining space mounted at /home (ZFS striped mirror pool, effectively RAID 10): all container data
The design logic is clean: reserve 20GB for the root filesystem with RAID protection for stability, and hand over the bulk of remaining space to a ZFS pool. The reason for using ZFS on /home is that the user wanted all containers to benefit from ZFS's enterprise-grade features — data integrity checksums, snapshots, compression, and more. This "separate system from data" architecture is a hallmark of professional storage planning.
Networking: Macvlan for Per-Container IPs
The network configuration is arguably the most technically sophisticated part of this build. Rather than settling for simple NAT forwarding, the user gave each container its own independent LAN IP address.
Key Network Configuration Points
- Host interface: statically assigned IP within the LAN subnet
- Podman Macvlan: assigns each container its own dedicated LAN IP address
- Kernel Macvlan Shim: a virtual bridge that solves the classic problem of hosts being unable to communicate directly with their Macvlan containers, while also allowing VPN traffic to be routed to containers
Anyone familiar with Macvlan knows its biggest pain point: by default, the host and its Macvlan containers cannot talk to each other. This user cleverly worked around that limitation by configuring a kernel Macvlan shim — preserving the benefit of containers having independent IPs, restoring host-to-container communication, and leaving a clean path for WireGuard VPN traffic routing. This reflects a genuinely deep understanding of the Linux networking stack.
Service Stack: Rebuilding the Proxmox Experience with Open Source Tools
One of the core challenges of this migration was assembling a collection of open source tools that together replicate the integrated experience Proxmox provides. The user's service choices are quite representative.
Management and Monitoring Layer
- Cockpit Web GUI: serves as the Proxmox web interface replacement, used for remote host management, system status monitoring, and resource usage tracking. Developed primarily by Red Hat, Cockpit has become a popular lightweight alternative to heavy virtualization panels.
- Uptime Kuma: a service availability monitoring tool running in Podman, used to track the uptime of DNS, VPN, DDNS, and other critical services with a visual dashboard.
- Ntopng: also running in Podman, used for real-time network traffic monitoring. It listens on the host's network interface and provides analysis of all inbound and outbound traffic.
Network Services Layer
- Technitium DNS: configured with local authoritative forward and reverse lookup zones, with custom A/PTR records for LAN devices and WireGuard peers. Block lists are also added to filter trackers, telemetry, and ads — effectively a self-hosted Pi-hole-level network ad blocker.
- WireGuard VPN: provides secure remote access.
- DDNS configuration: handles dynamic public IP resolution for home internet connections.
Taken together, this service stack covers the core needs of a home server — management, monitoring, DNS, VPN, and dynamic DNS — all built on open source software with containerized deployment, making it highly maintainable and portable.
Key Takeaways and Design Principles
Why Podman Instead of Docker
One noteworthy decision is the choice of Podman over the more mainstream Docker. Podman's daemonless architecture and superior rootless support give it a security edge, and it aligns well with the mindset of someone who wants fine-grained control over their system.
Learning Value Over Convenience
Migrating from Proxmox to a hand-built Debian 13 setup is fundamentally a trade of convenience for control and depth of understanding. Everything Proxmox abstracts away — ZFS management, network configuration, virtualization scheduling — needs to be implemented manually here. The process is tedious, but every step deepens your understanding of Linux storage, networking, and container technology.
For tech enthusiasts who want to move beyond "knowing how to use tools" toward "understanding how they work," this kind of migration project has real reference value. It proves that with mature open source components like Cockpit, Podman, ZFS, and Technitium DNS, you can absolutely build a home server that rivals commercial virtualization platforms in functionality.
Reusable Design Principles
Overall, this setup embodies several design principles worth adopting:
- Separate system and data storage: root partition uses BTRFS, data partition uses ZFS — clear separation of responsibilities
- Comprehensive RAID protection: RAID 10 from SWAP to the data pool, balancing performance and redundancy
- Independent network identity per container: Macvlan gives each service its own IP, simplifying firewall and routing management
- Complete monitoring coverage: Cockpit + Uptime Kuma + Ntopng covers system, service, and network monitoring across all three dimensions
These principles scale well to larger self-hosted server deployments. Whether you're a homelab newcomer or an experienced sysadmin, there's something valuable to take away here.
Related articles
DeepSeek V4 Pro Burning Through Credits Too Fast? The Hidden Logic Behind AI Model Pricing
Why does DeepSeek V4 Pro drain credits so fast while Flash barely moves? A deep dive into AI token billing, Pro vs. Flash pricing differences, and cost optimization tips.
RealPDE Competition Breakdown: The Frontier Challenge of AI-Powered Real-World Fluid Dynamics PDE Solving
A deep dive into the NeurIPS 2026 RealPDE Competition, covering the Sim2Real and LTTTA tracks, and how neural operators tackle real-world PIV and CFD fluid PDE challenges.
Building a Production-Grade 3DGS Training Library from Scratch: A Deep Dive into Full-GPU Residency and the Vulkan Stack
A veteran graphics engineer builds a production-grade 3DGS training library from scratch using C++23, CUDA, and Vulkan, achieving 60fps with 5M splats. Deep dive into its architecture and design.