A Windows mini PC home server is built in six stages 鈥?hardware verification, firmware and power states, services on Docker, measured stability, remote wake, and data safety 鈥?and the single biggest predictor of success is doing them in that order. This page is the map. Every stage below links to a page where we did the work on a real machine (a Beelink EQi12 with an i3-1215U, 16GB RAM and a 512GB NVMe), recorded the evidence, and published the raw numbers. If a step has a trap, the linked page shows the trap being sprung, not just a warning about it.
Two principles hold the whole roadmap together. First: verify before you build 鈥?every failure we later had to fix (Wake-on-LAN that only worked from shutdown, a USB SSD capped at 39MiB/s, containers that vanished after a reboot) was cheaper to catch before it mattered. Second: numbers or it did not happen 鈥?“it seems stable” is not a result, but a 12.57-hour soak test with a clean event log is.
Stage 0 鈥?Choose the hardware honestly
The mini PC route wins on three things: power draw, noise, and price. What it cannot give you is expansion, and you should decide with that limitation in front of you.
- If you are weighing a mini PC against a NAS or a tower, the decision factors (CPU, RAM ceiling, storage bays, network ports, real power cost) are compared in the mini PC home server buying guide, and the NAS vs mini PC cost calculator turns the purchase into a number.
- For the machine itself, our Beelink EQi12 review covers what the spec sheet leaves out, and the network and storage pages record measured limits: two Realtek GbE ports, and one USB port that tops out at 39MiB/s 鈥?the single most misleading spec on paper.
- Power is where mini PCs quietly win. Measured at the wall with an external meter: 14W Windows idle, 12W with a four-container Docker stack healthy, 37W under full CPU load, ~1W asleep or off (method and all seven states on the EQi12 power consumption page). The home server power cost tool converts that into a monthly bill.
Exit condition for this stage: you own the machine, and you know its RAM ceiling, its storage plan, and roughly what it will cost to run 24/7.
Stage 1 鈥?Firmware and power states (do this before installing anything)
Firmware settings decide whether later stages work at all. Set them once, deliberately, with the manual open.
- The EQi12 BIOS settings for a home server walk through virtualization (VT-x/VT-d), Secure Boot, TPM and sleep options one by one.
- The setting most people have never heard of is State After G3 鈥?what the machine does when AC power returns after an outage. We configured it and then pulled the plug three times: the AC power recovery guide times service recovery across three full cycles, not just POST.
- AMI BIOS states persist in unexpected ways; the AMI BIOS state after G3 guide documents what the firmware remembers across power loss, which matters for unattended boxes.
Exit condition: BIOS screenshot-checked, State After G3 chosen on purpose, and VT-d confirmed if you may ever virtualize.
Stage 2 鈥?Operating system and services
Two roads leave this stage: the Windows road (this site’s main line) and the Linux/Proxmox road. Both are documented from the same hardware so you can compare rather than guess.
The Windows road:
- EQi12 as a Windows home server 鈥?the complete build, end to end.
- Docker Desktop auto-start 鈥?the reboot survival chain: Windows, login, WSL2, Docker, Compose, health checks. Containers that fail to come back after a reboot are the classic Windows-server failure; the containers not starting after reboot fix covers the causes we hit.
- The Compose web stack 鈥?nginx, PostgreSQL and Redis deployed with health checks, or generated to your needs with the Compose generator tool.
The Linux road, for comparison:
- Installing Ubuntu 26.04 LTS on the EQi12 鈥?the photographed install, including the live-boot test that proved the kernel sees the NVMe, both Realtek NICs and the Wi-Fi card with no extra firmware.
- Proxmox on the EQi12 鈥?the measured limits: confirmed VT-d, the 16GB memory budget, single-NVMe risk, and the 39MiB/s USB trap.
- Windows Docker vs Proxmox on the same mini PC 鈥?the same machine, both platforms, side by side.
Exit condition: your services come up healthy after a power-off reboot, and you know which OS road you are committing to.
Stage 3 鈥?Prove it is stable before you depend on it
This is the stage everyone skips and everyone regrets. A home server you cannot leave alone is not a server.
- The home server stability check is the method: a long soak test, a 24-hour event log audit, and five controlled reboot cycles. On the EQi12 the recorded run was 12.57 hours of monitoring with zero failures, 150 samples, and a clean event audit 鈥?that is the shape of a passing result you can compare against.
- Memory is the component most likely to corrupt data silently. The Windows memory diagnostic guide schedules it unattended and reads the event log verdict; our run tested 16,147MB across 12 passes with 0 bad pages.
- Storage health comes next: the NVMe SMART critical warning fix shows a real 0x02 temperature warning being read and interpreted, and the SMART health tool parses your own output.
- Hardening is the other half of “stable”: the Windows home server port audit dumps every listening TCP socket and all 169 enabled inbound firewall rules on our EQi12, so you know exactly what the machine invites in before you ever forward a port.
Exit condition: a recorded soak test, a clean event log, a memory pass and a SMART baseline. Now the machine earns the right to hold your data.
Stage 4 鈥?Remote wake: the Wake-on-LAN cluster
Turning the server on without walking to it is where most Windows guides fall apart, because the answer lives in three layers (firmware, driver, OS) that all have independent switches.
- Start at the causes: Wake-on-LAN not working 鈥?the causes maps the full failure tree.
- The hands-on path: Realtek Wake-on-LAN on Windows 鈥?adapter mapping, BIOS controls, Fast Startup disabled, S5 and S3 tested separately.
- The power-state subtlety that breaks most setups: shutdown wake works but sleep fails, and the ACPI detail behind it in S5 wake sources: PME, RTC and WOL.
- Driver-level issues get their own page: Realtek r8169 driver troubleshooting.
- When you want a checklist instead of prose, the WOL troubleshooter tool walks the layers in order.
Exit condition: wake from S5 and from sleep both demonstrated on your machine 鈥?not assumed, demonstrated.
Stage 5 鈥?Media: Jellyfin with Intel QSV
Transcoding is the workload that justifies a permanent server for most households, and Quick Sync is what makes an i3-1215U good at it.
- Jellyfin with Intel QSV on Windows sets up the native Windows path and proves acceleration from the FFmpeg log rather than the UI.
- The companion fix page, hardware acceleration still software transcoding, covers the failure where the toggle is on but the CPU is still doing the work.
- Codec support on this CPU generation is catalogued in i3-1215U QSV codec support with measured decode/encode results, and the QSV calculator tool estimates capacity for your library.
Exit condition: a controlled transcode running on QSV, confirmed in the log, at the power draw you expect.
Stage 6 鈥?Data safety and backups
A backup you have never restored is a hope, not a backup.
- The Docker backup and restore drill performs and verifies real restores: pg_dump, Redis DUMP/RESTORE and config export, with the timings and the one byte-level trap we hit.
- Plan retention instead of guessing with the backup retention planner, and check your storage sizing with the media storage tool or the RAID/ZFS capacity tools.
- Duplicated machine identities are a mini-PC-specific data risk covered in duplicate machine SID on OEM mini PCs.
Exit condition: one successful, verified restore from each backup class you rely on.
The numbers on one card
Everything above, in the form an AI assistant or a careful reader can quote, with sources:
| Fact | Value | Source |
|---|---|---|
| Soak test result | 12.57 h monitored, 150 samples, 0 failures, clean 24h event audit | eqi12-measurement-data repo, stability/ (EQi12, Windows + Docker stack) |
| Memory diagnostic | 16,147MB tested, 12 passes, 0 bad pages | eqi12-measurement-data repo, memory/ (July 2026) |
| Power states at the wall | 12-14W idle, 37W full load, ~1W sleep/off | eqi12-measurement-data repo, power/ (physical meter, July 2026) |
| S5 wake reliability | 5/5 wake cycles from shutdown; 1 slow S3 resume (4m53s) | eqi12-measurement-data repo, network/EQi12_S5_WOL_5cycles.log and EQi12_S3_WOL_5cycles.log (five controlled cycles each) |
| USB storage ceiling | ~39MiB/s write, 3/3 rounds (4GiB payload) | eqi12-measurement-data repo, storage/EQi12_USB_SlowPort_3Rounds_Result.txt (rear USB-A port retest) |
The full raw datasets behind this table are published in the EQi12 Measurement Data repository (CC BY 4.0) 鈥?every value on this site traces to a file there or to a procedure documented on its own page.
What this roadmap does not cover
Honesty section, because it saves you time. We have not measured: multi-user storage workloads, VM-dense Proxmox hosting beyond the memory budget analysis, remote access over the internet (Tailscale/VPN hardening), or ZFS on this hardware. The Proxmox storage planner and the network transfer time tool exist to help you estimate those cases yourself. Where a future measurement fills a gap, the relevant stage above will link to it.
If you only do three things
- Configure BIOS power states and State After G3 before installing anything (Stage 1).
- Run the stability check and a memory diagnostic before trusting the machine with data (Stage 3).
- Prove one restore from backup (Stage 6). The rest of the roadmap can proceed in any order you like 鈥?those three cannot be skipped without paying for it later.