1. Immich → replaces Google Photos / iCloud Photos

Immich has closed the gap with commercial photo backup faster than almost anything else in the self-hosted space. Automatic mobile backup, facial recognition, timeline view, shared albums — it’s there. The real cost isn’t the software, it’s the storage: budget for real redundancy (see: data hoarding pillar) since you’re now responsible for not losing your own photos.

Run it if: you already have or are willing to build reliable storage. Skip it if: you don’t have a backup plan for the backup — self-hosted photo storage without off-site backup is a single point of failure, not an upgrade.

2. Vaultwarden → replaces 1Password / LastPass

Vaultwarden is a lightweight, Rust-based reimplementation of the Bitwarden server, compatible with all the official Bitwarden client apps. This is the lowest-risk item on this list — minimal resource footprint, mature codebase, and password managers are exactly the kind of tool that benefits from you controlling the data.

Run it if: you can commit to keeping it patched and backed up — a password vault is not the place to get lazy about updates.

3. Jellyfin → replaces Plex Pass / Netflix (for your own media)

Jellyfin is fully open source with no paid tier gating hardware transcoding or major features, which is the whole reason people migrate from Plex in the first place. Client app support has caught up on most platforms, and transcoding works well if you’ve got a GPU to offload it to.

Run it if: you already have a media library. Skip it if: you’re expecting it to replace actual streaming services with current releases — that’s not what this replaces.

4. Paperless-ngx → replaces document scanning subscription services

Point a scanner (or your phone) at it, and Paperless-ngx OCRs, tags, and indexes documents automatically. It’s one of the more genuinely life-improving self-hosted apps because the payoff is immediate: searchable PDFs of every bill, receipt, and piece of mail you’ve fed it.

Run it if: you actually have a document backlog to deal with. It’s a low-maintenance, “set it up once and feed it forever” kind of service.

5. Uptime Kuma → replaces paid uptime monitoring

If you’re running any of the above, you need to know when they go down. Uptime Kuma is a clean, actively maintained status-monitoring tool with notification integrations for basically everything (Discord, email, ntfy, ping, ports). It’s the smallest app on this list and arguably the most important — self-hosting without monitoring means you find out things broke when you go looking for them, not when they happen.

The honest trade-off

None of this is free in the way “free” gets used in marketing. You’re trading a monthly bill for your own time, your own backups, and your own uptime. For these five, that trade is worth it because the software is mature and the failure modes are well understood. For anything less mature, read the data-hoarding and hardware guides here before you commit real data to it.

What redundancy actually protects against

Redundancy (RAID-Z1, RAID-Z2, mirrors, whatever flavor) protects against drive failure, full stop. It does not protect against:

• Accidental deletion (redundancy dutifully replicates your mistake)
• Ransomware or file corruption that writes bad data (same problem)
• Fire, theft, flooding, or anything that takes out the whole box at once
• Controller or power supply failure that kills multiple drives simultaneously

That’s what backups are for, and it’s a separate problem from redundancy. This post is specifically about the “how many drives can I lose without losing data” question.

The real risk: rebuild time

The reason “just run RAID-Z1 with one parity drive” advice has gotten worse over time isn’t the math — it’s drive size. Rebuilding a failed 4TB drive from parity used to take hours. Rebuilding a failed 20TB drive can take a day or more, and during that entire window, your array has zero redundancy left. If a second drive fails — and rebuild stress is exactly when a second aging drive tends to fail — you lose the pool.

This is why RAID-Z1 (single parity) has fallen out of favor for anything beyond small arrays of smaller drives, and why RAID-Z2 (dual parity) has become the practical default for larger pools.

A sizing framework, not a rule of thumb

Instead of “always run Z2,” work through this:

1. How many drives are in the vdev? More drives means more chances for a second failure during a rebuild. A 4-drive vdev is a different risk profile than a 12-drive vdev.
2. How big are the drives? Bigger drives mean longer rebuilds mean longer exposure windows. Scale your parity up as your drive size goes up.
3. How replaceable is this data? A media library you could re-rip is a different risk tolerance than family photos or financial records that exist in exactly one place.
4. Do you actually have a backup for the important subset? If yes, you can run leaner redundancy on the pool since a rebuild failure isn’t catastrophic — it’s an inconvenience you recover from with the backup.

Practical starting points

• Small pool (4-6 drives, ≤8TB each), backed-up critical data: RAID-Z1 is defensible. Watch your drive ages and replace proactively.
• Larger pool (8+ drives) or drives above 12TB: RAID-Z2. The rebuild window is long enough that single parity is gambling.
• Anything truly irreplaceable: mirrors (RAID-10 equivalent) or RAID-Z2 and an off-site backup. Redundancy buys you uptime during a drive failure; it does not buy you disaster recovery.
• Very large pools (16+ drives): consider RAID-Z3 (triple parity) or splitting into multiple smaller vdevs rather than one giant one — a single huge vdev means a single huge rebuild.

The one habit that matters more than any RAID level

Monitor drive health (SMART data, zpool status, scrub schedules) and replace drives showing early warning signs before they fail outright, not after. A proactive swap on a healthy array is a non-event. A failure during a rebuild is how pools actually get lost. Redundancy buys you a safety margin — monitoring is what tells you when you’re about to need it.

The short answer

If you’re starting fresh in 2026, run Proxmox VE. It’s free, actively developed, has a real community, and does everything most home labs need — VMs, LXC containers, clustering, ZFS, and a web UI that doesn’t feel like an afterthought. The rest of this post is for the “but why” crowd.

Proxmox VE

Proxmox is a Debian-based hypervisor with KVM for VMs and LXC for containers side by side — that combination alone is a big reason it’s become the default homelab choice. Containers are lighter than VMs for anything Linux-native, and you’re not stuck picking one virtualization model for your whole cluster.

Strengths:

• No licensing tier that suddenly starts asking for money (there’s a paid support subscription, but the software itself is fully functional without one)
• Native ZFS support, including boot-drive ZFS mirrors
• Clustering is built in and doesn’t require a separate management VM
• LXC containers for anything that doesn’t need full VM isolation — dramatically lower overhead for things like Gitea, Pi-hole, or a reverse proxy

Weaknesses:

• Hardware compatibility list is less exhaustive than VMware’s — check your NIC and storage controller before committing
• The web UI, while functional, is not going to win design awards

VMware ESXi

ESXi used to be the default recommendation, largely because so many admins learned virtualization on it professionally. That’s changed. Broadcom’s acquisition of VMware reshaped licensing hard, and the free ESXi tier that homelabbers relied on for years is effectively gone. You can still find hardware compatibility and vMotion-style live migration that’s genuinely more polished than the alternatives — but you’re now evaluating whether that polish is worth what it costs, in money or in workaround effort, for a home environment.

Where it still makes sense: if your day job is VMware administration and you want your homelab to mirror production, or you already have valid licensing through work.

XCP-ng

XCP-ng (built on Xen) is the option most people haven’t tried and probably should look at more. It’s fully open source, backed by Vates, and pairs with Xen Orchestra for management — which, notably, is also free if you’re willing to build it from source instead of paying for the pre-built appliance.

Strengths:

• Genuinely open source top to bottom, no asterisks
• Live migration and other “enterprise” features aren’t locked behind a paywall
• Solid track record for stability

Weaknesses:

• Smaller community than Proxmox means fewer guides for oddball problems
• Xen Orchestra’s free tier requires you to build from source and self-update — the paid appliance is otherwise the easy path

What actually matters for a home cluster

Three things separate a good choice from a regret six months in:

1. Hardware support. Check your specific NIC, storage controller, and any passthrough devices (GPUs especially) against each platform’s compatibility notes before you commit, not after.
2. Container vs. VM mix. If most of what you’re running is Linux services, Proxmox’s LXC support saves real RAM and disk over VM-only platforms.
3. What happens when it breaks. Proxmox and XCP-ng both have active forums where real answers show up fast. That matters more than any single feature when you’re debugging a broken cluster at 11pm.

For most home setups in 2026, Proxmox remains the pragmatic default — free, well-documented, and flexible enough to grow with a cluster instead of forcing you into a redesign later.

This is the exact pattern used to stand up production services on a real cluster: each app gets its own lightweight LXC (not a shared Docker host), unprivileged where possible, on whatever bridge/VLAN you tell it to use.

What’s in the box

• playbook.yml — the main playbook; deploy one app or all three
• roles/vaultwarden/ — Bitwarden-compatible password manager
• roles/uptime-kuma/ — uptime/status monitoring for everything else you self-host
• roles/paperless-ngx/ — document scanning, OCR, and search
• roles/common/ — shared LXC provisioning logic (template download, container creation, base hardening)
• inventory.example.ini — copy to inventory.ini and fill in your Proxmox host details

Requirements

• A Proxmox VE host reachable over SSH with a user that can run pct (does not need to be root)
• Ansible 2.15+ on your control machine
• A Debian 12 LXC template already downloaded, or let the playbook fetch one for you

Get it

Checkout is handled by Stripe. This is a digital download — no physical shipping.