TechFuel HQ

Jellyfin Remote Access: Pick the Right Path for Your Situation (2026)

LK Wood IV — Tue, 25 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-25 · ~12 min read · St. Louis County, MO

Jellyfin does not have a relay. That single architecture fact generates the question this page answers. When a Plex user hits play from a hotel, Plex’s own infrastructure brokers the connection; when Plex put that convenience behind a paywall in 2025, the migration wave toward Jellyfin began, and every migrant hit the same wall about a week in. Jellyfin gives you a checkbox that says Allow remote connections to this server and leaves the actual path from the outside world to your basement entirely to you.

The r/jellyfin community answers this question so often that a post sitting at 279-plus upvotes as of late August 2026 is literally titled “I’m kinda tired of the constant remote access questions” — 250-plus comments of people relitigating the same four options. Listing the options was never the hard part. Matching one to your situation is. So this guide routes first and explains second.

TL;DR · Route yourself before reading anything else

Your situation	Use this
Just you, on your own phone and laptop	Tailscale (Path 1)
You + household, every device can install apps	Tailscale, apps on each device (Path 1)
Family elsewhere, watching on smart TVs	Reverse proxy + your own domain (Path 2)
Family elsewhere on TVs, but your ISP uses CGNAT	VPS relay: Pangolin or WireGuard bounce (Path 3)
Non-technical viewers who will not install anything	Reverse proxy - a URL in a browser is the only universal client (Path 2 or 3)
Hotel room / a TV you do not own	Travel streaming stick with Tailscale, or laptop + HDMI (device table below)
Roku in another house	Reverse proxy or VPS relay - no Tailscale client exists for Roku
Tempted by Cloudflare Tunnel because it is free	Read Path 4 first - video streaming sits against Cloudflare's CDN terms

Why “just use Tailscale” keeps failing people

Tailscale is the default answer in every thread, and for the person asking, it is usually right. It is also the answer I give for a solo setup, so this is not a takedown. The failures cluster in one place: the devices you do not control.

Tailscale reaches a device by running a client on it. The client coverage is better than most people assume in 2026 - there is an Android TV app in the Play Store, an Amazon Appstore app for Fire TV (most devices after 2018, though Tailscale states it does not support the Fire TV Stick 4K Select), and an Apple TV app. But Tailscale’s supported-platform list ends there for TVs. No Roku. No LG webOS. No Samsung Tizen. Jellyfin ships official apps for all three, so the missing piece is the network path. Your mother-in-law’s Roku can run Jellyfin; it cannot run your VPN.

The second failure is human. A tailnet wants an account relationship with every participant: you either share devices to their Tailscale account or manage logins for them. For a household that tolerates you, fine. For the relative who calls when the TV “stopped working,” each moving part you added is a future phone call. The 100-plus-comment version of this complaint is “I’m eyeing Jellyfin (currently use Plex w/ a Lifetime pass)”, a holder of the old Plex deal asking whether Jellyfin can match that remote simplicity for non-technical family - and the honest answer is: only if you build the path that needs nothing installed, which is Path 2.

So run Tailscale when you control the endpoints, and something with a plain HTTPS URL when you do not.

Path 1: Tailscale (or another mesh VPN)

This is the path for you, your own devices, and a household that installs apps. It costs $0. The free Personal plan covers up to 6 users with unlimited devices, which is most homes.

The mechanics are in our Tailscale homelab guide — client on the server, client on each viewer, then the Jellyfin apps talk to http://<tailscale-ip>:8096 from anywhere. The Jellyfin Docker guide covers the server side in Step 6. Traffic stays WireGuard-encrypted end to end, nothing is exposed to the internet, and CGNAT does not matter because every connection is outbound.

Two honest caveats. Battery and cellular behavior on phones is solved, but every viewer’s device must keep its VPN toggled on, and the failure mode when it silently is not - “your server is down” - lands on you. And if you would rather self-host the coordination server too, that is Headscale, with the same client math.

Do not confuse this path with Tailscale Funnel, which publishes a tailnet service to the open internet through Tailscale’s relays. Tailscale documents Funnel traffic as subject to non-configurable bandwidth limits - a constraint that rules it out for pushing video at your family every evening.

Path 2: Reverse proxy + your own domain

This is the path for family on TVs and for viewers who install nothing, because any client with a browser or a Jellyfin app that accepts a URL can reach it. It needs a public IPv4 address and ports 80/443 forwarded on your router. The only recurring cost is an ordinary domain registration, since the proxy automates a free Let’s Encrypt TLS certificate.

This is the path I validated end to end while writing this guide, on a bare Windows box with no Docker, because the claim “a reverse proxy in front of Jellyfin is fiddly” deserved a test. It is not fiddly anymore. The sequence, timed:

Jellyfin 10.11.11 portable zip unpacked to a folder and started: about three minutes from download to a listening server on port 8096. No installer, no admin rights.
The setup wizard’s Set up Remote Access screen shows one checkbox — Allow remote connections to this server — already checked by default. I verified the shipped network config afterward through the API: remote access on, UPnP off, HTTPS off, Known Proxies empty. Jellyfin never opens your router for you and never brings its own TLS - both are deliberately your job, and both are exactly what the proxy provides.
Caddy as the proxy, one binary, and the entire working config is this:

media.yourdomain.com {
 reverse_proxy 127.0.0.1:8096
}

That is the whole file. With a real domain pointed at your IP, Caddy obtains and renews the Let’s Encrypt certificate on its own. Against my local instance I watched the three things that historically break proxied Jellyfin all come back clean: the web client served, logins authenticated, and the websocket upgrade returned 101 Switching Protocols with zero websocket-specific configuration. That last one matters because Jellyfin’s reverse-proxy docs warn that not every proxy passes websockets by default - nginx wants explicit upgrade headers, and the equivalent toggle is the classic missed step in Nginx Proxy Manager. Caddy is also what Jellyfin’s own docs recommend first, “for its ease of use.” On the same evidence, I concur. (Choosing between Caddy, NPM, and Traefik is its own comparison.)

One Windows-specific wrinkle from the test worth passing on: Caddy’s self-signed local mode pauses on an interactive certificate-trust prompt. Irrelevant for the real deployment - public certificates involve no local trust store - but if you dry-run with local_certs first, expect that prompt.

Two settings finish the job properly. Add the proxy’s IP to Known Proxies in Jellyfin’s networking settings, or every viewer shows up in your logs as the proxy’s address instead of their own - the docs flag this, and the fresh-install default I captured (empty list) means it is always on you to set. And leave Jellyfin itself listening on plain 8096 bound to localhost or the LAN; the proxy is the only thing that should face the world. Never forward 8096 directly - that is unencrypted HTTP with your login page on it, and it is the port-forward horror story the community warnings are actually about.

What kills this path is not skill. It is CGNAT - if your ISP does not give you a real public IPv4, no amount of port forwarding helps, and dynamic-DNS tricks change nothing. Check before you buy a domain. If your router’s WAN address falls in the 100.64.x-100.127.x range (RFC 6598 shared address space), or the “what is my IP” number differs from the router’s WAN number, you are CGNATed and you want Path 3.

Path 3: VPS relay - the CGNAT escape hatch

This fits everything Path 2 fits, for the case where the ISP will not give you a public IP or you refuse to open home ports. The going figure in the community threads is about $5/month for a small VPS.

The idea is to rent the public IP you do not have. A minimal VPS gets the public endpoint; your home server connects outward to it; visitor traffic enters the VPS and rides that outbound tunnel home. Three implementations, in ascending order of hand-holding:

WireGuard bounce - the DIY version. WireGuard on both ends, forwarding rules on the VPS. Full control, most assembly; our WireGuard on Proxmox guide covers the VPN half.
FRP (fast reverse proxy) - the same shape with a purpose-built tool, popular in the budget threads.
Pangolin - the project that broke out in 2026, and the reason this section is not just “run WireGuard.” It is a WireGuard-based, identity-aware tunneled reverse proxy: dashboard, per-app authentication, Let’s Encrypt handling, all self-hosted. Its own requirements state the deal plainly: a Linux server with a public IP, a domain, and ports 80/443 (TCP) plus 51820/21820 (UDP). At 22.5k GitHub stars it has become the default answer to “self-hosted Cloudflare Tunnel alternative,” and there is a managed free tier (5 users, 5 sites) if you want to try the model before renting anything.

The trade nobody advertises: every stream now transits the VPS, so your remote picture quality is capped by the VPS provider’s bandwidth and your home upload, whichever is worse. Budget VPS bandwidth caps are real; check the fine print against your bitrates before moving the family movie night onto one.

Path 4: Cloudflare Tunnel - free, easy, and built on someone else’s tolerance

Cloudflare Tunnel deserves its reputation for polish: outbound-only connector, free HTTPS URL, CGNAT-proof, no client software for viewers. For a wiki or a dashboard I recommend it without hesitation - the full comparison against Tailscale covers where it shines.

For Jellyfin specifically, read the terms before you build on it. Cloudflare’s service-specific terms, as published on 2026-08-25, state that unless you are an Enterprise customer, “Cloudflare offers specific Paid Services (e.g., the Developer Platform, Images, and Stream) that you must use in order to serve video and other large files via the CDN,” and that Cloudflare “reserves the right to disable or limit your access to or use of the CDN” if you serve “video or a disproportionate percentage of pictures, audio files, or other large files” without them.

Streaming your library through a free tunnel is exactly that. The record supports two observations at once. Enforcement against small personal servers is rare in practice — the community is full of people doing it quietly — and no threshold is published anywhere, so any “under X TB you’re fine” claim you read is folklore, not policy. Both things are true, and together they mean the availability of your family’s media server depends on a policy Cloudflare applies at its own discretion. That is a fine risk for an experiment and a bad foundation for the thing your household relies on. There is also a mechanical constraint that bites before the policy does: the 100 MB request-body cap on free plans breaks large uploads through the same hostname.

If the tunnel’s shape is what you want - outbound-only, no exposed home ports, URL for everyone - Pangolin in Path 3 is that shape with the policy risk replaced by a small VPS bill.

The device truth table

The rows are where remote-access plans actually die. “Works” here means the normal Jellyfin app experience over that path.

Device	Jellyfin app	Tailscale (Path 1)	Proxy/relay URL (Paths 2-3)	Reality check
Android / Google TV	Official	✅ Play Store client	✅	Best-covered TV platform: both paths work
Fire TV	Official (Android TV app)	✅ Amazon Appstore, most post-2018 devices; not the 4K Select stick	✅	The travel-stick platform of choice
Apple TV	Swiftfin / Infuse	✅ App Store client	✅	Tailscale’s only non-Android TV client
Roku	Official	❌ no client exists	✅	The single strongest argument for Path 2/3
LG webOS	Official	❌ no client	✅	Same story as Roku
Samsung Tizen	Official	❌ no client	✅	Same story as Roku
Xbox	Official	❌ no client	✅	Console app, URL-based access only
Phones / tablets / laptops	Official	✅	✅	Everything works; these were never the problem
Hotel / dorm TV	none of yours	via a stick you bring	✅ if the TV has a browser (rough)	See below

The hotel row earns its own paragraph, because a 90-plus-comment thread on it converged on answers that surprise people. Casting from your phone mostly fails in hotels: hotel Wi-Fi typically runs AP isolation, so your phone and a Chromecast cannot see each other even on the same network. The frequent travelers in that thread bring a streaming stick with Tailscale and Jellyfin already signed in, plug it into the room TV’s HDMI, and give the stick the hotel Wi-Fi — the tunnel is outbound, so captive portals and CGNAT do not matter. The road warriors in that thread report usable HDMI inputs in the large majority of rooms, with the occasional welded-on “hospitality mode” remote as the exception. The zero-cleverness fallback is a laptop and an HDMI cable. A GL.iNet-class travel router running the VPN for the whole room is the deluxe version of the same idea.

If you run Path 2 or 3, the hotel problem mostly dissolves. Your domain works in any browser, including the TV’s, and in any Jellyfin app on hardware you bring.

The security baseline, whichever path you picked

Paths 1 and 3-via-Pangolin put authentication in front of Jellyfin; Path 2 puts Jellyfin’s own login on the internet. Either way:

Password quality is the whole game on a public login page. Long, unique, per user, no shared “family” account with a weak password. Jellyfin’s account system is the only thing between a scanner and your library on Path 2.
Update the server. Jellyfin 10.11.11 is current as I write this; security fixes ride ordinary releases, and a version pinned in 2024 and forgotten is how exposed services rot. The setup guide covers the container-update flow.
Set Known Proxies (Path 2/3), or your access logs record the proxy talking to itself while real client addresses vanish - which also breaks any fail2ban-style banning you add at the proxy layer later.
Do not log full request URLs at the proxy. Jellyfin’s docs note it sometimes passes api_key in the URL; a proxy logging full paths writes credentials into its own logfiles.
Quick Connect ships enabled on a fresh 10.11.11 install - the code-based login on the sign-in page, verified on the test instance below. It is convenient for TV logins on your own tailnet; on a fully public instance, it is one more auth path you should consciously decide to keep or disable.

What I tested, and what I did not

The reverse-proxy path above is first-hand: Jellyfin 10.11.11 portable on Windows, Caddy 2.11.4 in front, wizard walked, defaults pulled from the live API, Quick Connect state read off the fresh install, websocket upgrade verified through the proxy, on 2026-08-25. The public-DNS leg ran against a local certificate authority rather than a routable domain, because I was not going to open ports on the network I ran the test from - the Let’s Encrypt half of Caddy’s job is its most automated part, but it is the one piece of Path 2 this test takes from documentation rather than observation. Tailscale’s TV-client coverage comes from Tailscale’s own install docs rather than a rack of TVs, and the hotel tactics come from the travel thread’s consensus, attributed as such; I have not road-tested them. I have not run Pangolin beyond its documentation and requirements - it is on the bench list, and if that test changes the Path 3 advice, this page moves with it.

Sources

Windows VM Won't Boot After the Proxmox 9 Upgrade? Read the Error Before You Reinstall (2026)

LK Wood IV — Tue, 25 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-25 · ~9 min read · St. Louis County, MO

The host reboot after a Proxmox VE 8-to-9 upgrade has a particular quiet moment. The console comes back. The containers go green. The Debian guests come up. And the one Windows VM lands on a blue recovery screen instead of a login: “Your PC/Device needs to be repaired… 0xc0000001. An unexpected error has occurred.”

Nothing inside Windows changed. That is the tell.

A guest that booted fine before the upgrade and refuses after it is reporting a change in the layer underneath — firmware type, disk controller, boot entries, or the host kernel itself. Which layer depends on what the failure looks like, and the failure tells you if you read it before touching anything. Reinstalling Windows, the move half the panic threads reach for, is the one response that cannot be right: it destroys a healthy guest to address a host-side change, and in the worst case reinstalls onto the exact configuration that triggers the bug.

I maintain the upgrade guide this page pairs with, and I want to be straight about sourcing: I have not reproduced this failure on a lab host. Every fix below instead names the community thread or vendor document that confirmed it, chiefly the Proxmox forum thread where the 0xc0000001 signature was worked to a confirmed fix, and the r/Proxmox reports that match it. Where a step was tried in those threads and did not work, I say that too. That list of dead ends is half the value here.

What the failure looks like

Four screens, four different problems. Match yours before running a single command.

The signature fork

The screen the VM stops on names the broken layer. Every fix in the ladder below belongs to exactly one of these forks — running fixes from the wrong fork is how a one-reboot problem becomes a weekend.

FORK A · HOST KERNEL

Blue recovery screen: 0xc0000001 “An unexpected error has occurred”

Reported on SeaBIOS + MBR guests the moment the host moved to kernel 7.0. Same VM boots fine on the previous 6.17 kernel.

→ Steps 1–2, permanent fix in Step 5

FORK B · EFI BOOT ENTRY

Drops to the UEFI boot menu or shell — picking the disk manually boots fine

The OS is intact; the auto-boot chain is not. Reported on OVMF guests after 9.2 point updates, worst with boot disks on IDE.

→ Step 3

FORK C · DISK CONTROLLER

BSOD: INACCESSIBLE BOOT DEVICE

The boot disk's bus type changed and Windows has no driver bound for it — usually self-inflicted mid-troubleshoot, or after a restore that changed the controller.

→ Step 4

FORK D · GUEST TYPE FLAGS

Instant reboot loop — no error screen at all

Reported on a UEFI Windows 11 guest on kernel 7.0.14: the VM resets before Windows draws anything. Fixed in-thread by correcting ostype from win10 to win11.

→ 30-second checks below

techfuelhq.com · signatures per forum.proxmox.com thread 183958 + r/Proxmox reports, mid-2026

One honest caveat on ordering. Nobody has failure-rate telemetry for this, me included, so the ladder below is ordered by cost of the test, cheapest and most reversible first. Anyone who tells you which of these causes is “most common” is guessing.

The 30-second configuration checks

Before changing anything, pull the VM’s config on the host and read five lines:

qm config <vmid>

bios: is ovmf or seabios (absent means SeaBIOS, the default). This decides which fork you are in. A UEFI Windows install needs ovmf; if this line says otherwise, something rewrote your config (a restore, a migration script, a manual edit).
efidisk0: must exist on every OVMF VM. An OVMF guest with no EFI disk has nowhere to store boot entries, and boot-entry loss is exactly the Fork B symptom.
machine: shows whether your virtual hardware moved. Windows VMs get their QEMU machine version pinned at creation (pc-q35-8.1, say) precisely because, in the words of the Proxmox reference documentation, “Windows is sensitive to changes in the virtual hardware.” If yours shows a pinned version, the upgrade did not move it. If it shows latest or a bare q35, the upgrade silently jumped your virtual hardware to QEMU 11’s newest revision.
scsihw: and the boot disk’s bus (scsi0: / sata0: / ide0:) matter for Step 4, so note what they are. If Windows last booted from a scsi0 disk and the disk now hangs off ide0, that mismatch is your Fork C.
ostype: should be win11 for the Windows 11 / Server 2022 / Server 2025 generation and win10 for Windows 10 / Server 2016 / 2019 — the qm.conf reference defines win11 as “Microsoft Windows 11/2022/2025” and win10 as “10/2016/2019”, and Server 2022 on the win10 setting is a common leftover. The forum thread’s reboot-loop case (Fork D) was resolved by exactly this one-line correction on a UEFI Windows 11 guest, so check it before deeper surgery.

Five lines, under a minute, and you have usually already picked your fork.

Why Proxmox 9 breaks Windows VMs and leaves Linux guests alone

The 8-to-9 upgrade is not one change. Landing on the current 9.2 means Debian 13.5, QEMU 11.0, and the Linux 7.0 kernel all arrive at once, and each is a layer a guest boots through.

The kernel is the loud one right now. Within days of kernel 7.0 reaching 9.2 hosts, the Proxmox forum thread above collected Windows Server guests failing with 0xc0000001 across three hosts with different storage back-ends — all SeaBIOS, all MBR boot disks, all fine again the moment the host booted the previous 6.17.13 kernel. The thread’s participants converged on a kernel regression affecting SeaBIOS/MBR guests specifically; no OVMF guest shows up among the failures, and one commenter reported his OVMF guests running fine on the same PVE version. As of this writing there is no Proxmox staff reply in that thread, so treat the diagnosis as strong community evidence rather than an official statement. The fix pattern it produced, though, was confirmed by two separate users in the linked discussion, which is more than most boot-failure folklore ever gets.

QEMU 11 is the quiet one. Windows VMs carry a pinned machine version for stability, so most survive the QEMU jump untouched. The r/Proxmox comments on the same failure confirm the corollary: rolling the machine version back (pc-q35-8.0) did not fix the 0xc0000001 failure. Machine versions matter at the margins. Guests set to latest get a large hardware jump, and QEMU’s own policy now removes machine versions from upstream after six years, so a config pinned to something ancient will eventually stop starting at all. Worth reading once and then not obsessing over.

And Windows itself is simply the fussy tenant. It refuses to boot from a disk bus it was not prepared for (the documented INACCESSIBLE BOOT DEVICE failure in Step 4), its Boot Configuration Data store assumes the firmware handoff never changes shape, and a BitLocker-protected guest treats TPM changes as a reason to demand its recovery key. Linux guests and containers re-enumerate most of this on every boot and move on. That asymmetry (host change, Windows-only casualty) is the entire diagnostic frame of this page.

The fix ladder, least invasive first

Each step says what it does, when it is the right one, and how to undo it.

Step 1: update the host before you change the VM

The bug you hit may already be fixed. One commenter in the boot-menu thread reports a similar failure (his word — similar, not identical) that cleared up with a later Proxmox kernel or qemu-server update. Check and apply point updates on the host, reboot, and re-test the VM before touching its config.

apt update && apt dist-upgrade

When it is the one. Always first. It costs a host reboot and nothing else, and every later step benefits from being on current packages. How to revert. Nothing to revert.

Step 2: boot the previous kernel — the confirmed 0xc0000001 fix

This is Fork A’s move, and it doubles as its diagnostic. Proxmox keeps the previous kernel installed; proxmox-boot-tool can select it, and the selection works on both systemd-boot and GRUB hosts:

proxmox-boot-tool kernel list
proxmox-boot-tool kernel pin 6.17.13-13-pve --next-boot
reboot

--next-boot applies for one boot only. If the Windows VM comes up normally on 6.17 (as it did for the reporters in the forum thread, whose guests failed on kernel 7.0.6-2 and booted on 6.17.13-13), you have confirmed the kernel fork in one reboot with zero permanent changes. Then make it stick until you are ready for Step 5:

proxmox-boot-tool kernel pin 6.17.13-13-pve

The cost is real, and I want it on the page: a pinned host is not running the kernel line that receives current fixes. You are trading an unbootable guest for a slightly stale host, which is the right trade this week and the wrong one forever. Record the pin somewhere you will see it, re-test on each new point release, and proxmox-boot-tool kernel unpin the day the current kernel boots your guests again. If you run GPU passthrough, you may already know this dance. Kernel pinning is the same escape hatch the passthrough community reaches for when a new kernel breaks VFIO.

Step 3: repair the UEFI boot path — when manual boot works

Fork B has the friendliest tell in the whole taxonomy: press Esc at the VM’s firmware splash, pick the Windows disk by hand, and it boots perfectly. The OS is fine. Only the automatic handoff is broken. Three sub-fixes, in cost order:

Boot order first. VM → Options → Boot Order. After upgrades and restores this list can end up pointing at the wrong device or de-selecting the boot disk entirely. Fix, cold-boot (full stop/start, not a guest reboot), done.

Get the boot disk off IDE. In the r/Proxmox thread where two of four Server 2022 guests dropped to the boot menu after a 9.2.9 update, the affected disks hung off IDE, and a commenter identified the mechanism as the BCD not supporting IDE EFI boot chaining, which is exactly why manual selection worked while auto-boot failed. Moving the boot disk to SCSI resolved it, with one caveat the reporter hit honestly — Windows needed a Safe Mode boot to bind the storage driver on first start after the move. Do it in Step 4’s driver-safe order rather than a blind detach/re-attach.

Rebuild the EFI vars and TPM state. This is the heavier variant, reported working across a fleet. Detach and delete the VM’s EFI disk and TPM state, re-add both fresh, and — the detail that made it stick — reset the TPM to factory keys before the first boot. The thread’s reporter found a plain rebuild did not stick (Windows booted once, then the failure returned on the next reboot); the commenter who recovered roughly two dozen VMs adds the factory-key reset before first boot as the step that makes it hold. Nobody in-thread tested the two variants side by side. Before you touch either disk, have your BitLocker recovery key in hand. Clearing the TPM is on Microsoft’s own list of events that put a BitLocker device into recovery, so expect the recovery prompt at next boot — and without the key that screen is a lockout.

When it is the one. The manual-selection tell, or an OVMF guest whose efidisk0 is missing or damaged. How to revert. Boot order and controller moves reverse in the GUI; a deleted EFI/TPM disk does not come back, which is why the recovery key comes first.

Step 4: swap the disk controller without losing boot

Fork C is the one you can give yourself mid-troubleshoot, and the shape of it is worth thirty seconds. When the boot disk arrives on a bus Windows has not booted from before, Windows can fail before it is up — the standard explanation is that boot-critical storage drivers are only armed once Windows has actually used them. Whatever the exact mechanism, Proxmox’s driver documentation states the outcome flatly: installing the VirtIO drivers and switching the boot disk in one step “will result in a blue screen, claiming an ‘INACCESSIBLE BOOT DEVICE’.”

So the swap is a two-boot procedure, per that same document:

Load the virtio-win ISO in the VM’s CD drive and attach a small temporary disk (1 GB) on the VirtIO SCSI bus.
Boot Windows, install the drivers, and wait until the temp disk shows up in Disk Management. That appearance is the proof the driver is genuinely bound.
Shut down. Remove the temporary disk, then detach the boot disk and re-attach it on the target bus (SCSI on the VirtIO SCSI single controller is what Proxmox’s Windows best-practices guide has you pick).
Fix Options → Boot Order to point back at the boot disk, boot, and take the ISO out once you are up.

If you are already stuck on the blue screen because the bus changed underneath you, put the disk back on the old bus first. That is the one-minute undo (detach, re-attach on the previous bus type, restore boot order), and Windows boots because the old driver is still the one it trusts. Then do the procedure above properly. And a warning from the founding thread worth repeating: controller shuffling was tried against Fork A’s 0xc0000001 and did nothing — VirtIO SCSI single versus VirtIO SCSI, iothread on or off, none of it moved that failure. Controller surgery fixes controller problems. It does not fix kernel problems.

Step 5: convert SeaBIOS/MBR to UEFI — the permanent Fork A fix

The kernel pin in Step 2 avoids the wedge; this removes it. The wedge condition is SeaBIOS firmware booting an MBR disk, so the reporter converted his Windows guests to UEFI/GPT and ran them on kernel 7.0 without issue — “everything runs now fine,” in his words in the r/Proxmox comments after migrating his whole fleet — and a second user in the same discussion, after converting his Server 2025 guest the same way, closed with “everything is ok.”

Inside Windows, validate before you commit. mbr2gpt refuses ineligible layouts (more than three primary partitions, extended/logical partitions present), and per Microsoft’s documentation BitLocker protection must be suspended first:

mbr2gpt /validate /allowFullOS
mbr2gpt /convert /allowFullOS

The conversion rewrites the partition table in place, creates the EFI system partition, and migrates the BCD. Data stays, but there is no un-convert command, so this is a tested-backup-first operation. Then shut down and flip the Proxmox side to match, because a GPT disk under SeaBIOS boots nothing:

Hardware → Add → EFI Disk.
Options (or Hardware → BIOS) → change SeaBIOS to OVMF (UEFI).
Re-check Boot Order, cold-start, and expect one trip through the firmware menu if the fresh EFI vars need the Windows Boot Manager entry selected once.

When it is the one. Fork A guests you want back on the current kernel line, done one VM at a time in a maintenance window. I would not run it on a domain controller before its backup restore had been tested. The tool is fine; “no undo command” plus “untested backup” is the combination you only get burned by once. How to revert. You do not; you restore.

Step 6: restore the pre-upgrade backup

If you took the tested backup the upgrade guide insists on, the calm exit was available the whole time. Restore the guest as it was, pin the kernel if the restored VM still hits Fork A, and schedule the UEFI conversion for a quieter week. A restore also cleanly unwinds a troubleshooting session that changed five things: restored config, restored disk, known state.

If you did not take one, let this be the page that converts you. Every fork above is survivable with a backup and console access; several are miserable without. The 3-2-1 setup takes an evening.

What not to do

Do not reinstall Windows. Wrong layer. The guest is healthy; the platform moved. In the kernel-regression case a fresh install onto SeaBIOS/MBR can hit the same wall on first boot.
Do not detach and re-attach disks “to see if it helps.” Every detach can drop the disk from the boot order, stacking a Fork B problem on top of whatever you had. Config changes here should be single, deliberate, and written down.
Do not upgrade the rest of the cluster while node one’s Windows guests are down. The failure travels with the kernel, and so does your blast radius. Diagnose on one node; pin or fix before the next node moves.
Do not run fixes from the wrong fork. The reporter’s threads already burned the hours for you: against 0xc0000001, controller swaps did nothing, iothread toggles did nothing, machine-version rollback to pc-q35-8.0 did nothing, and a QEMU 10-vs-11 switch did nothing. The kernel pin worked. The UEFI conversion worked. Match the signature, run its fix.

Prevent it on the next node

Everything above compresses into three pre-upgrade lines for whatever you upgrade next:

qm config every Windows guest and record bios / machine / boot bus / ostype. Thirty seconds per VM, and it turns any post-upgrade surprise into a diff instead of a mystery.
Convert SeaBIOS/MBR Windows guests to UEFI before the host jumps to kernel 7.0, on your schedule instead of during an outage.
Take the tested backup. Then run the full pre-flight checklist (pve8to9, NIC pinning, console access) and upgrade knowing the escape hatches on this page exist but expecting not to need them.

The upgrade itself is routine. The preparation is the whole job — and for Windows guests specifically, the preparation now includes knowing which firmware they boot with.

Sources

Proxmox forum — “Windows Server 2025 fails to boot after PVE 9.2 / Linux 7.0 Kernel upgrade” (the 0xc0000001 thread; kernel versions, controller/iothread and QEMU 10-vs-11 non-fixes, the ostype win10→win11 boot-loop fix): https://forum.proxmox.com/threads/windows-server-2025-fails-to-boot-after-pve-9-2-linux-7-0-kernel-upgrade.183958/
r/Proxmox — the same failure’s discussion thread (three hosts, SeaBIOS/MBR/VirtIO SCSI, broken 7.0.6-2-pve vs working 6.17.13-13-pve; machine-version-rollback non-fix; both UEFI-conversion confirmations): https://www.reddit.com/r/Proxmox/comments/1trztwg/
r/Proxmox — Server 2022 guests dropping to the boot menu after 9.2.9, manual disk selection working; IDE/EFI boot chaining diagnosis, EFI+TPM rebuild fix, the similar-failure-fixed-by-update report: https://www.reddit.com/r/Proxmox/comments/1vgbstt/
Proxmox wiki — Paravirtualized Block Drivers for Windows (the temporary-disk procedure and the INACCESSIBLE BOOT DEVICE warning, quoted verbatim): https://pve.proxmox.com/wiki/Paravirtualized_Block_Drivers_for_Windows
Proxmox wiki — Windows 10 guest best practices (SCSI bus on the VirtIO SCSI single controller for Windows guests): https://pve.proxmox.com/wiki/Windows_10_guest_best_practices
Proxmox wiki — Host Bootloader (proxmox-boot-tool kernel list / pin / –next-boot / unpin): https://pve.proxmox.com/wiki/Host_Bootloader
Proxmox VE reference documentation — QEMU/KVM Virtual Machines (Windows machine-version pinning, machine-version removal policy): https://pve.proxmox.com/pve-docs/chapter-qm.html; ostype value definitions (win10 = 10/2016/2019, win11 = 11/2022/2025): https://pve.proxmox.com/pve-docs/qm.conf.5.html
Microsoft Learn — MBR2GPT (validate/convert syntax, /allowFullOS, disk prerequisites, BitLocker suspension, UEFI firmware requirement): https://learn.microsoft.com/en-us/windows/deployment/mbr-to-gpt
Microsoft Learn — BitLocker recovery overview (“Turning off, disabling, deactivating, or clearing the TPM” as a recovery trigger): https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/recovery-overview
Proxmox VE roadmap — 9.2 release contents (Debian 13.5, kernel 7.0, QEMU 11.0), verified 2026-08-25: https://pve.proxmox.com/wiki/Roadmap

Ollama vs llama.cpp Throughput: Same-GPU Compare Dataset

LK Wood IV — Thu, 20 Aug 2026 01:10:00 -0500

By LK Wood IV · Published 2026-08-20 · ~3 min read · St. Louis County, MO

The short version

I ran both servers on one GPU across three models. Same box. Same settings. llama.cpp b10507 wins decode by 2-6% on dense models and by 13-22% on the gpt-oss MoE; Ollama 0.32.1 wins real-prompt prefill by 4-7%. VRAM matches within 7 MiB wherever the two load the same file. The raw engine (llama-bench) runs 367 t/s on the 3B where the full Ollama stack runs 319, so the entire serving stack costs about 13%.

Download: llm-server-compare-2026-08.csv. CC BY 4.0, per-run decode arrays included.

The measured configurations

Model	Server	Decode	Prefill (long)	GPU mem (MiB)	Load
Llama 3.2 3B	Ollama 0.32.1	319 t/s	17,444 t/s	4,343	3.2s
Llama 3.2 3B	llama.cpp b10507	338 t/s	16,809 t/s	4,339	2.5s
Qwen 2.5 14B	Ollama 0.32.1	99.4 t/s	5,004 t/s	10,941	5.6s
Qwen 2.5 14B	llama.cpp b10507	101.4 t/s	4,697 t/s	10,942	8.1s
gpt-oss 20B	Ollama 0.32.1	195.8 t/s	—	14,152	8.6s
gpt-oss 20B	llama.cpp (upstream GGUF)	222-238 t/s²	—	13,037	19.8s

² Prompt-dependent on this MoE: a fixed prompt held 232-242 t/s (median 238.5); varied prompts were bimodal with a ~176 slow path (median 235.3), and the published 222 median includes a cold first run. Ollama’s fork ran a flat 195.7-196.3 under the same nonce scheme. Load times are cold-start to first ready response: llama-server was faster on the 3B, Ollama faster on both larger models.

The desktop baseline was 1,642 MiB of GPU memory before any model loaded (nvidia-smi reports MiB; the CSV column is vram_total_mib_median). These figures run 2-7% above our RTX 5080 throughput dataset for the same models because that capture used 500-1,650-token prompts; both pages state their regime.

Method

I kept one server resident at a time, with a fresh process per model and ollama stop plus process-tree kills between configurations. Every request carried a unique nonce prefix, llama-server additionally ran with prompt caching disabled, and generation was pinned to temperature 0, seed 42, 256 tokens (64 on the long-prefill pass), context 4096, full offload. Rates are each server’s own counters; a wall-clock recomputation agreed within 2% on every run (one cold-start exception at 3.6%, disclosed above), and llama-bench served as a third instrument on the 3B (pp512 19,589 ± 2,071 t/s, tg256 367.1 ± 0.7 t/s, raw engine loop). The capture scripts are available on request via hello@techfuelhq.com.

The limits, named. One GPU, one box, three models, default server flags, and a short-prompt prefill column retained only to document its own overhead artifact. Token counts for identical text differ slightly between servers because Ollama applies its chat template to /api/generate while llama-server’s /completion takes prompts raw. The decision-layer writeup is the companion article; this page is the citable record.

Ollama vs llama.cpp on an RTX 5080: Measured (2026)

LK Wood IV — Thu, 20 Aug 2026 01:00:00 -0500

The argument shows up in every local-AI thread: Ollama is “just a wrapper” and real performance lives in bare llama.cpp. Nobody arguing it ever posts numbers from the same machine. So I ran both servers on the same RTX 5080, loading the same GGUF bytes, with generation pinned to temperature 0, seed 42, and fresh prompts every run.

The answer surprised me, because I went in expecting to confirm the forum consensus and instead measured something smaller, stranger, and more useful. The wrapper costs almost nothing, and each side wins one event.

Decode goes to llama.cpp. Prefill goes to Ollama. Nobody wins big.

The measured table

Ollama 0.32.1 versus llama.cpp b10507 (llama-server), full GPU offload, 4096 context, 256-token generations, decode medians of five runs. Prefill measured at real prompt length (~420 tokens), median of three fresh runs with a discarded warmup. The short version of why the prompt length matters is below.

Model	Server	Decode	Prefill	GPU mem (MiB)
Llama 3.2 3B	Ollama	319 t/s	17,444 t/s	4,343
Llama 3.2 3B	llama.cpp	338 t/s	16,809 t/s	4,339
Qwen 2.5 14B	Ollama	99.4 t/s	5,004 t/s	10,941
Qwen 2.5 14B	llama.cpp	101.4 t/s	4,697 t/s	10,942
gpt-oss 20B	Ollama	195.8 t/s	—	14,152
gpt-oss 20B	llama.cpp²	222-238 t/s	—	13,037

² Upstream GGUF (the Ollama blob refuses to load; see the portability catch below). gpt-oss is a mixture-of-experts model and its decode rate on upstream llama.cpp is prompt-dependent: a fixed prompt held a tight 232-242 t/s (median 238.5), while varied prompts were bimodal, mostly ~230-243 with a ~176 slow path — honest range 175-243, varied-prompt median 235.3. The published 222 median also carries a cold first run at 186. Ollama’s fork ran a flat 195.7-196.3 under the same nonce scheme. The gpt-oss prefill cells are dashed because the long-prompt pass was not run on this model.

Desktop baseline was 1,642 MiB of GPU memory; subtract it for the models’ own footprints. Wall-clock recomputation agreed with each server’s self-reported rates within 2% on every run but one — the first gpt-oss run on llama-server landed 3.6% off, a cold-start artifact. Wherever both servers loaded the same file, VRAM matched within 7 MiB. Same weights, same memory. The gpt-oss row is the exception, and it is carrying two different conversions of the model, not a wrapper difference. These figures also run 2-7% above our earlier RTX 5080 throughput dataset for the same models, because that capture used 500-1,650-token prompts where this one uses short ones; both pages state their regime.

llama.cpp decodes 2-6% faster on the dense models, more on the MoE below. Ollama prefills 4-7% faster at real prompt sizes. Neither gap changes what a model feels like to use, and neither survives a driver update, an engine release, or a quantization change as the deciding factor in a purchase or a migration.

The overhead ladder

One more instrument makes the picture honest. llama.cpp ships llama-bench, which times the raw engine loop with no server in front of it. On Llama 3.2 3B:

Instrument	What it measures	Decode
llama-bench	bare engine loop	367 t/s
llama-server	+ HTTP serving, sampling pipeline	338 t/s
Ollama	+ model management, its serving stack	319 t/s

Each layer costs single-digit percent, and that is the entire “wrapper tax”: 13% from the bare engine loop to the most convenient tool in the stack, most of it spent on serving machinery that any usable setup needs anyway, whichever side of the argument you started on. Forum threads promise dramatic slowdowns. None reproduced here.

That is the whole controversy, measured.

How my first measurement lied to me

The first pass of this bench used a short, ~40-token prompt, and it showed Ollama’s prefill rates landing 32-55% above llama-server’s — a gap that turned out to be an artifact, because at tiny prompt sizes “prefill tokens per second” is dominated by fixed per-request overhead rather than compute, which means it measures which server shuffles a request faster rather than which one ingests your context faster, and re-measured at ~420 prompt tokens, llama-server’s prefill jumped from ~5,300 to ~16,800 t/s on the 3B while the gap collapsed to single digits. The flags people credit for prefill speed did nothing here either: flash attention on or off, micro-batch 512 or 2048, all within noise at real prompt length on this card. Flags were not the story. Prompt length was.

So treat one-line-prompt prefill numbers as request plumbing, not throughput.

The portability catch

Ollama stores weights as standard GGUF blobs, and ollama show <model> --modelfile prints the path. Point llama-server at it and both tools share one copy of the weights. That worked perfectly for Llama 3.2 3B and Qwen 2.5 14B.

It failed for gpt-oss:20b, and the failure is worth knowing about. llama.cpp refused the blob with unknown model architecture: 'gptoss', and the server died on the spot. Ollama’s conversion tags the architecture with its own name, while upstream llama.cpp expects gpt-oss — so the one model Ollama co-launched is the one whose Ollama download you cannot carry to the upstream engine, so its download does not travel. The fix is downloading the upstream GGUF separately, at the cost of a second ~12GB copy on disk. The upstream copy then decoded 13-22% faster than Ollama’s fork on most prompts and allocated 1.1GB less GPU memory at the same context, so the annoyance bought something real, about 1.09 GiB of it.

Which one should you run?

Run Ollama when you want model management to be someone else’s problem: pulls, updates, memory eviction, an OpenAI-style API on 11434, and every tutorial on the internet assuming you have it. Our RTX 5080 throughput dataset and the RTX 5060 local LLM guide both ride on it for exactly that reason.

Run llama-server when you want the newest engine the day it ships, exact control over batching, context, and sampling, or the last few percent of decode speed. For these models the engines share llama.cpp lineage; Ollama’s README lists llama.cpp among its supported backends, and the gpt-oss arch tag shows it also ships its own engine paths. You are choosing how much of the engine’s surface to touch. Throughput is the wrong reason to switch in either direction — 2-6% is less than the gain from one quantization step or one driver update.

Method and limits

Both servers ran the same sha256-identical GGUF blobs from Ollama’s own store (except the gpt-oss case above), one server resident at a time, fresh process per model, with ollama stop and process-tree kills between runs. Every request used a unique prompt nonce; llama-server additionally got cache_prompt: false. Generation pinned to temperature 0, seed 42, 256 tokens (64 for the long-prefill pass), context 4096 on both. Rates come from each server’s own timing counters, cross-checked by wall-clock recomputation (within 2% throughout) and by llama-bench as a third instrument.

The limits, named. One GPU, one box, three models, servers on default flags. Token counts for identical prompt text differed slightly between servers (433 vs 407 on the long prompt) because Ollama applies its chat template to /api/generate while llama-server’s /completion takes the prompt raw — rates are per-token, so the comparison holds, but byte-identical inputs produce slightly different token streams. Ollama’s engine is a vendored llama.cpp build, so some of the decode gap is simply engine version lag, and it will move with every release on both sides. Date everything; this page says 2026-08-20.

MCP Server Resource Benchmark: RAM, Startup, Tools Dataset

LK Wood IV — Thu, 20 Aug 2026 00:48:00 -0500

By LK Wood IV · Published 2026-08-20 · ~3 min read · St. Louis County, MO

The short version

I benchmarked eleven of the most-recommended MCP servers for what they cost to keep resident. The answer: 178-422MB of RAM each (median 188MB), ready in 0.5-1.9 seconds warm, with tool counts from 1 to 26. A realistic concurrent five-server stack totals 961.6MB, and two independent measurement paths confirmed that figure to the decimal. Tool count barely predicts weight. The runtime and framework dominate.

Download: mcp-server-bench-2026-08.csv. CC BY 4.0, per-iteration arrays included.

The measured table

Server	Version	Ready	RSS	Tools
GitHub (legacy npm)	0.6.2	547ms	178MB	26
Playwright	1.63.0-alpha-2026-08-05	618ms	227MB	24
Time (Python)	1.29.0¹	619ms	181MB	2
Sequential-thinking	0.2.0	666ms	186MB	1
Memory	0.6.3	667ms	187MB	9
Filesystem	0.2.0	692ms	188MB	14
Git (Python)	1.29.0¹	699ms	185MB	12
Fetch (Python)	1.29.0¹	717ms	220MB	1
Context7	4.0.2	815ms	214MB	2
Desktop Commander	0.2.47	1,705ms	275MB	26
Qdrant (Python, 3.12 pin)	1.29.0¹	1,881ms	422MB	2

¹ The four Python servers self-report 1.29.0 via serverInfo. That is a framework version string rather than each package’s own release number.

Controls on the same box: bare Node resident loop 52.1MB, bare Python loop 15.2MB. Five-server concurrent stack components: memory 189.8, filesystem 187.1, fetch 221.7, git 184.5, GitHub 178.5. Total: 961.6MB.

Method

Each iteration spawns the server fresh (npx or uvx, warm package cache after one discarded warmup), completes the MCP initialize handshake over stdio, requests tools/list, then samples RSS across the full descendant process tree. I report medians of five iterations, three for the two servers benched later the same evening, marked in the CSV. The bench script lives in our repo at ops/bench/mcp/mcp_bench.py. For the decision layer, meaning which servers earn their memory and which to skip, read the companion article.

Known limitations, named: one Windows 11 machine, warm caches, stdio transport only, readiness and listing timed rather than per-tool-call latency under load. The GitHub entry is the legacy npm package; GitHub’s current first-party server ships as a Go binary and hosted remote. Version 1.0.0 of this dataset; changes will be logged in the update history above.

Unraid vs TrueNAS vs OMV vs Proxmox: NAS OS Pick (2026)

LK Wood IV — Thu, 20 Aug 2026 00:30:00 -0500

Every NAS thread ends in the same four names, and one of them does not belong. I spent an evening verifying the current state of all four against their own release notes, pricing pages, and documentation, because so much of the standing advice on this comparison describes products that no longer exist, and the details that changed are exactly the ones that decide the purchase: TrueNAS SCALE is gone as a name, TrueNAS CORE is discontinued as a product, Unraid’s “subscription” is not one, and Proxmox, the name that starts half the arguments, does not serve a single network share out of the box and never claimed it could.

Here is the decision, then the evidence.

The short version

Two are free. One is worth paying for. One is a hypervisor wearing a costume.

Mixed drives you already own, apps with minimum friction, money available: Unraid. Uniform drives, integrity as the priority, 8GB of RAM to spare: TrueNAS Community Edition. A weak or small box, Debian comfort, zero budget: openmediavault. And if virtual machines are the actual point of the server, run Proxmox — with a NAS on top of it, not instead of one.

The August 2026 state of play

	Unraid	TrueNAS CE	openmediavault	Proxmox VE
Version	7.3.2 (Jul 2026)	25.10.6 (Aug 2026)	8.5.6-1 (Aug 2026)	9.2 (May 2026)
Cost	$49 / $109 / $249 once	Free	Free	Free²
Storage	mixed-size parity array	ZFS only	mdadm + 16 mountable filesystems	for VM disks, not shares
RAM floor¹	none published	8GB	1GiB	1GB (2GB + guests)
Apps	Community Apps (Docker)	TrueNAS Apps (Docker)	omv-extras plugins	VMs + LXC only

¹ Official documentation figures; Unraid’s getting-started docs publish no RAM number (only a 4GB USB stick requirement) and its forum moderators suggest 4GB as the practical minimum. ² Subscriptions run €120 (repo access only, no tickets) to €1,100 (unlimited tickets) per socket per year; the free package repo is officially labeled not recommended for production.

What the old comparisons get wrong

The rename nobody indexed. TrueNAS SCALE became TrueNAS Community Edition with 25.04 “Fangtooth” in April 2025, and the FreeBSD-based CORE line is formally finished. The software status page says it is no longer under active development, with 13.0-U6.8 and 13.3-U1.2 as the final builds. Any comparison still weighing “CORE vs SCALE” is a museum piece.

Unraid’s pricing produces the loudest arguments and the most misinformation. The licenses are perpetual. The $36 a year on the Starter and Unleashed tiers is optional and only gates new feature releases; your installed version keeps working and keeps receiving security patches within its minor version. Lime Technology shipped 7.2.8 with a WebGUI CVE fix three weeks after 7.3.2 was already current. Call it a subscription and its forum will correct you, with citations.

RAIDZ expansion stopped being a differentiator. TrueNAS shipped it in 24.10 in October 2024, sponsored by iXsystems, and Unraid’s ZFS pools gained the same one-drive-at-a-time growth in 7.2.0 a year later. The classic “ZFS can’t grow one disk at a time” objection is two years stale against TrueNAS and ten months stale against Unraid.

openmediavault deserves both its reputation and its asterisk. It is the lightest real NAS OS here, it is genuinely free, and the third-party omv-extras mergerfs and SnapRAID plugins recreate Unraid’s mixed-drive economics without the license fee. The asterisk is structural: the GitHub contributor graph shows 8,303 commits by the lead developer against 24 by the next contributor. One maintainer carries the core. OMV 7 also quietly went end-of-life in June 2026, so a fresh install today should start at OMV 8.

The category error

Proxmox VE describes itself as a server management platform for enterprise virtualization. Its storage documentation lists NFS and SMB only as backends it mounts from somewhere else, to hold VM disks and backups. There is no interface anywhere in it for creating a share, and its community answers the recurring question without hedging: “not a NAS software like TrueNAS,” in its own words. That settles it.

So why is it in every NAS thread? Because homelabbers correctly run it as the base layer and put the NAS on top — a TrueNAS or OMV virtual machine with disks passed through, a fileserver LXC, or bare Samba on the underlying Debian. All of those work. None of them makes Proxmox a NAS OS; they make it a hypervisor hosting one, which is a different decision with different failure modes. If that is your situation, the real question is which storage backend to run under Proxmox, and we compare exactly that separately.

Picking by your actual constraint

Your drives are a mixed bag. Unraid’s parity array takes different sizes in one protected pool, and openmediavault reaches the same shape via the third-party omv-extras mergerfs and SnapRAID plugins. TrueNAS will let you mix sizes but charges you for it: ZFS caps every disk in a vdev at the smallest member’s capacity.

Your RAM is tight. TrueNAS officially wants 8GB plus 1GB per drive past eight. OMV officially runs in 1GiB. On a repurposed thin client or an N100 with soldered memory, that spread decides the argument by itself.

You want apps without ceremony. Unraid’s Community Apps store is, in my judgment, the smoothest catalog in home NAS. TrueNAS moved its apps backend from Kubernetes to plain Docker in 24.10, which simplified life, though its forums carry real migration scars from that transition, and the forum threads from the 25.04 virtualization overhaul read the same way. OMV needs the omv-extras compose plugin before Docker exists at all.

Your data is the point and nothing else is. TrueNAS. It is not close, because the whole platform is organized around one job: ZFS end-to-end with checksumming, snapshots, and replication, maintained by a company whose paying enterprise customers keep the storage layer honest whether or not the home users complain loudly enough.

Budget rules everything. OMV and TrueNAS are free. Unraid’s $49 Starter covers six attached devices, which fits most first builds; count your drives before assuming the $109 tier. Run your drive plan through the RAID capacity calculator first — parity overhead changes the real cost per usable terabyte more than the license does.

Whatever wins, put it on hardware that idles politely. A NAS runs 24/7, so the idle-power economics compound annually, and the budget NAS builds and old-PC conversion guide both start from that premise.

Method and limits

Everything above was verified on 2026-08-20 against official release notes, pricing pages, and documentation, with community claims labeled as community claims; the source list below carries the URLs. Two honesty notes from the verification run: the openmediavault docs site blocks automated fetchers, so its facts were checked against the project’s own docs source repository (identical content), and a small number of forum items were verified through search-index snippets rather than full page loads. What this page is not: a hands-on bench of the four installers side by side. I have not run these four concurrently on matched hardware, so you will find no throughput or power numbers here — when we measure that, it will publish as a dataset with the raw files, like our other measured work. Versions move fast in this space; if the table above and a vendor page ever disagree, the vendor page has moved and this page’s lastmod tells you by how much.

Best MCP Servers for a Homelab: 11 Measured (2026)

LK Wood IV — Wed, 19 Aug 2026 23:58:00 -0500

All four “favorite MCP servers” roundups I could find share one gap. None publishes a single number. No memory footprint, no startup time, no latency. Enumerate and vibe is the format. So I wrote a small benchmark, pointed it at eleven of the most-recommended MCP servers, and measured what they actually cost to keep resident on a homelab box.

The headline: each server holds 178-422MB of RAM, and the popular advice to “just connect everything” costs about 1GB for five servers, because I measured 961.6MB for a real concurrent stack, two independent measurement paths agreed on it to the decimal, and that is a gigabyte gone before a single model or container starts, spent on tooling I touch a few times a day. Nobody mentions this. RAM is the quiet bill.

The measured table

Fresh spawn per iteration, warm package cache, five iterations per server (three for GitHub and Qdrant, benched later the same evening — the iterations column in the CSV says which), medians reported. RSS covers the full process tree, because npx and uvx both spawn children, and measuring only the parent undercounts 18x. Raw data ships as CSV with a versioned dataset page, CC BY 4.0.

Server	Version	Ready	RSS	Tools
GitHub (legacy npm)	0.6.2	547ms	178MB	26
Playwright	1.63.0-alpha-2026-08-05	618ms	227MB	24
Time (Python)	1.29.0¹	619ms	181MB	2
Sequential-thinking	0.2.0	666ms	186MB	1
Memory	0.6.3	667ms	187MB	9
Filesystem	0.2.0	692ms	188MB	14
Git (Python)	1.29.0¹	699ms	185MB	12
Fetch (Python)	1.29.0¹	717ms	220MB	1
Context7	4.0.2	815ms	214MB	2
Desktop Commander	0.2.47	1,705ms	275MB	26
Qdrant (Python, 3.12 pin)	1.29.0¹	1,881ms	422MB	2

¹ The four Python servers self-report the version string 1.29.0 via serverInfo, a framework string rather than each package’s own release number.

Controls matter here. A bare Node process idles at 52MB and bare Python at 15MB on the same box, so the gap between those floors and the table is frameworks plus dependencies. Your tool code is nearly free. Tool count barely predicts weight. The 26-tool GitHub server is the lightest thing I measured, while the 1-tool sequential-thinking server still costs 186MB. The framework is the payload.

Two findings surprised me. Python servers land as heavy as Node ones, since uvx resolves an environment and spawns its own interpreter chain; fetch holds 220MB for a single tool. And the whole startup-cost worry is mostly noise for homelab use. Everything except Desktop Commander and Qdrant is ready in under a second warm, and a persistent client like Claude Code spawns servers once per session anyway.

The tiers, with the criteria stated

I ranked on four things I can defend: measured cost, utility per megabyte, install friction, and whether the server works standalone or needs a service running behind it.

Tier 1, connect these first

Filesystem (188MB, 14 tools), Fetch (220MB, 1 tool), and Git (185MB, 12 tools). These are the hands and eyes of any local AI setup. They read and edit real files, pull real web pages, and work actual repository history. Every workflow I run daily leans on at least two of the three, so their megabytes never idle.

Tier 2, worth it when the use exists

GitHub (178MB, 26 tools) earns a slot if your work lives in issues and PRs. The npm package I measured is the legacy implementation; GitHub’s current first-party server ships as a Go binary and a hosted remote endpoint, so treat 178MB as the worst case. Playwright (227MB, 24 tools) puts an agent behind a real browser, and the 227MB is just the idle server, so budget for the browser on top. Memory (187MB, 9 tools) gives an agent a persistent knowledge graph across sessions, which pays off once you have sessions worth remembering. Desktop Commander (275MB, 26 tools) is the heaviest Node server, and at 1.7s only Qdrant starts slower. It earns that by being a full terminal-and-editor surface. Run it where you would trust an agent with a shell, and nowhere else.

Tier 3, think twice

Sequential-thinking is the worst utility-per-megabyte in the table. It holds 186MB for one tool that restates a reasoning pattern current models handle natively. Context7 (214MB, 2 tools) pulls current library docs into context, which helps coding agents and duplicates a client that already fetches the web. Qdrant is the heaviest measured at 422MB, and bare uvx failed to install it outright on this machine — the resolver picked a pydantic-core it had to source-build, which dies without a Rust toolchain. Pin it with uvx --python 3.12 mcp-server-qdrant and it starts fine, then holds its FastEmbed embedding model (all-MiniLM-L6-v2 by default) inside that 422MB. Run it if you already run Qdrant for something else.

The service-bound layer I did not measure

The service-bound servers the homelab press centers on need their platform running to mean anything. Proxmox MCP is the consensus pick, covered by three of the four roundups I checked, with one author counting 200+ exposed tools. Kubernetes MCP and Docker Desktop’s MCP Toolkit round out that set. This bench box runs neither Docker nor Proxmox, so those numbers would have been theater, and I left them out. The pattern from the measured set almost certainly transfers. Expect the runtime floor plus dependencies, call it 200-400MB per server, and measure on your own box before trusting anyone’s table, including mine.

Configs beyond Cursor

Three of the four roundups I read assume Cursor, and the fourth stays client-agnostic. Two clients they skip matter in a homelab. Claude Code wires a server in one line.

claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem C:/lab

LM Studio and Claude Desktop take the same JSON shape in mcp.json.

{
 "mcpServers": {
 "filesystem": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-filesystem", "C:/lab"]
 }
 }
}

Swap npx -y <package> for uvx <package> on the Python servers, and remember the Qdrant interpreter pin from the table above.

What to run this on

The RAM math is friendly. A five-server stack costs about 1GB resident, so any N100-class mini PC with 16GB handles the tooling layer without noticing. The real constraint is whatever model or services run beside it. If the same box also hosts a local LLM, size memory for the model first. Our RTX 5080 throughput dataset and the local LLM on an RTX 5060 guide carry the VRAM numbers. Mine are measured on this bench. The 5060 guide’s come from published benchmarks for those cards. With DDR5 prices where they are, over-provisioning system RAM is the cheapest insurance in the build.

Method, including the traps

The bench script (ops/bench/mcp/mcp_bench.py in our repo) spawns each server fresh, speaks MCP JSON-RPC over stdio with an initialize handshake followed by a tools/list call, and samples RSS across the full descendant process tree 0.4s after the listing returns. Five iterations per server, three for the two late additions. One discarded warmup spawn keeps npm and uv package caches warm, because the documented condition is a configured homelab, and never a first install. Run-to-run ready-time spread stayed under 7% for eight of eleven servers; the Python time and fetch servers carried first-iteration outliers up to 17%, visible in the published arrays. RSS spread stayed within 8MB worst case.

The instrument hit traps, so yours does not have to. Measuring only the spawned npx parent reports 10.3MB while the full process tree holds 189.3MB — an 18x undercount, recorded in the evidence set. Sum the tree. My first Git-server runs timed out because I pointed the repository flag at a plain directory, and the server waits silently. The Qdrant failure looked like a hang until stderr showed the build dying: “Failed to build pydantic-core==2.33.2 … Rust not found, installing into a temporary directory”. Bare uvx had resolved a pinned pydantic-core and fallen back to a source build; the 3.12 interpreter pin sidesteps it. For the five-stack figure the components were memory 189.8, filesystem 187.1, fetch 221.7, git 184.5, and GitHub 178.5, totaling 961.6MB by psutil; an independent PowerShell WorkingSet64 walk over the same process trees returned 961.6MB, exact agreement.

Limitations, named. One Windows 11 machine. Warm caches. Stdio transport only. I measured readiness and listing, and never per-tool-call latency under load. The GitHub entry is the legacy npm package rather than the current Go binary. Linux numbers will differ, likely lower on the Node floor, and that comparison is a natural v2 alongside the service-bound servers once this lab runs Docker.

RTX 5080 LLM Power Efficiency: Measured Watts and Joules per Token

LK Wood IV — Wed, 19 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-19 · ~5 min read · St. Louis County, MO

The short version

The RTX 5080 throughput dataset answers “how fast” — this companion answers “at what electrical cost.” Same retail card, same ollama stack: I logged board power at 1Hz with nvidia-smi while driving fixed-length generations through four models from 3B to 20.9B parameters, then divided each run’s decode rate by the watts that produced it. The result is the number almost nobody publishes for consumer cards: joules per token, and from it, real dollars per million tokens at the current EIA US residential electricity average of $0.184/kWh.

Two findings up front. First, the sparse-MoE gpt-oss 20B beats the dense 7B on tokens per joule (0.665 vs 0.53) and doubles the dense 14B (0.317) — active-parameter count and quantization set the electric bill, not total size. Second, the quiet budget-killer: this card measures 52–71W at idle in my system — not the 8–15W reference figure reviews quote — which at 24/7 duty is $85–115/year before a single token is generated.

The numbers (capture 2026-08-19, stock 448W power limit)

Model	Quant	Decode tok/s (med)	Board W (med, loaded)	Tokens/joule	Wh per 1M tokens	$ per 1M tokens
Llama 3.2 3B	Q4_K_M	318.3	265.2	1.20	231	$0.043
Qwen 2.5 7B	Q4_K_M	182.2	343.6	0.53	524	$0.096
Qwen 2.5 14B	Q4_K_M	98.8	311.6	0.32	876	$0.161
gpt-oss 20B	MXFP4 (MoE)	194.4	292.4	0.67	418	$0.077

Loaded-basis medians: telemetry samples counted only at GPU utilization ≥ 50%. Decode rates are ollama’s own eval counters (fresh prompt every iteration — cached-prompt runs report prefill artifacts, not decode). Full column set including clocks, temperature, VRAM, and per-run min/max is in the CSV.

What the data says

Sparsity beats size. gpt-oss 20B is the second-most efficient model on the card despite carrying the most total parameters — 0.67 tokens/joule against the dense 7B’s 0.53 and the dense 14B’s 0.32. It is a mixture-of-experts design that activates only a fraction of its weights per token, shipped in MXFP4, so it decodes at 194 tok/s while drawing less power than the 7B. If your workload fits its quality profile, the 20B is both the smartest and the second-cheapest model per token in this ladder — the dense-model intuition that “bigger costs more electricity per token” fails here.

Board power barely moves; efficiency moves 4x. Across a 7x spread in total parameters, loaded board power stays inside a narrow 265–344W band — the card runs at 59–77% of its 448W limit no matter what I feed it, and never once touched the cap. The 7B is the thirstiest of the four (343.6W): it generates fast enough to keep the memory bus saturated while still lighting up plenty of compute. What actually separates the models is the numerator — tokens delivered per second — which is why tokens-per-joule spans 0.32 to 1.20 while watts span barely 30%.

The marginal token is nearly free; the idle hours are not. Even the least efficient row costs $0.161 of electricity per million tokens — a full novel’s worth of output for under two cents at the May-2026 EIA residential average. Set against the idle finding below (52–71W around the clock ≈ $85–115/year), the budget conclusion for a home inference node inverts the usual framing: model choice barely matters to the bill; what the box does during the other 23 hours dominates it. Temperatures never passed 52°C at a 30% fan median, and the 448W cap was never reached — which also means a power-limit sweep should cost little throughput, and that is exactly the queued v1.1.

The idle-power finding

Every 24/7 cost model I have seen for this card starts from single-digit idle watts. Mine doesn’t idle there: across repeated captures this week the card sat between 52W and 71W at the Windows desktop, pinned in P0 with graphics clocks near 2.9GHz — multi-monitor output holds the high P-state, an animated wallpaper added ~6W and 2% utilization on its own, and the cleanest state I could produce (wallpaper closed, no model resident) still read 53.7W. This is a known behavior class, not a defect, but it is the number an always-on node actually pays: at $0.184/kWh, 52–71W around the clock is 456–622 kWh ≈ $85–115/year of pure idle. If your 5080 box mostly waits for occasional inference, the idle line, not the inference line, dominates the bill — check your own card with nvidia-smi --query-gpu=power.draw --format=csv before trusting any spec-sheet idle figure, mine included.

Method, exactly

Card: ASUS ROG Astral RTX 5080 OC (the same physical card as the throughput dataset and the Astral bench dataset), stock 448W power limit, driver-default clocks.
Host: Ryzen 7 7800X3D, 64GB DDR5-6000, Windows 11, ollama 0.32.1.
Workload: ollama run <model> --verbose generating from a fixed ~60-word prompt with a unique per-iteration prefix (defeats ollama’s prompt cache, which otherwise reports cache-hit rates that measure nothing). Three iterations per model.
Telemetry: nvidia-smi --query-gpu=power.draw,clocks.gr,temperature.gpu,utilization.gpu,memory.used,... polled at 1Hz for the whole profile window; the published watts are medians over samples with utilization ≥ 50% so idle seconds between iterations never dilute the load figure.
Pairing: each efficiency figure divides a profile’s median decode rate by that same profile’s median loaded watts — never a rate from one run by watts from another.
Decode, not prefill: the parser anchors on ollama’s eval rate: line start; a substring match also catches prompt eval rate: and silently records prefill — a bug these capture scripts had and fixed, documented in the scripts themselves.

Limitations, honestly

One prompt shape. Single-stream interactive decode from a short prompt; batch serving, long-context prefill, and draft-model setups will land elsewhere. The throughput dataset covers context scaling; its decode rates are the canonical speed numbers for this card.
Board power only. nvidia-smi reports GPU board draw — CPU, RAM, fans, and PSU efficiency losses are excluded. Wall draw for the whole box runs higher; my measured whole-rig figures live in the perf-per-watt article.
Stock power limit only (for now). The obvious next axis — the same ladder at 400/350/300W caps — needs an elevated shell for nvidia-smi -pl; that sweep is queued as v1.1.
Windows + this driver. P-state and idle behavior differ across OS/driver/monitor configurations; the 70W idle is my system’s truth, not a universal constant.

Use the data (CC BY 4.0)

Cite as “TechFuelHQ RTX 5080 LLM power-efficiency dataset, v1.0.0”. The table CSV is at /data/rtx-5080-llm-power-efficiency.csv; the raw 1Hz telemetry CSVs (one per run) and the capture manifest are in /data/rtx-5080-llm-power-efficiency-raw/. Attribution: TechFuelHQ / Lowell K. Wood IV, link to this page.

Change log

1.0.0 (2026-08-19) — initial publication: 4-model stock-power ladder (3B/7B/14B/20.9B), loaded-basis power medians, joules-per-token and $/Mtok at $0.184/kWh, raw telemetry CSVs, idle-power finding.

Best Motherboards for Ryzen 7 9800X3D (2026)

LK Wood IV — Tue, 18 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-18 · 14 min read · St. Louis County, MO

The three boards at a glance

The 9800X3D reaches full gaming speed on a well-built mainstream board. These picks buy three different layouts; CPU performance stays in the same class, so every dollar above the B850 default must purchase a port, lane, form factor, debug control, or expansion path the build will use.

Pick	Best for	The features that justify it	Aug. 17 reference
MSI MAG B850 Tomahawk Max WiFi	Best ATX value for most builds	PCIe 5.0 x16, Gen5 M.2, Wi-Fi 7, 5GbE, strong 80A-stage listing	$209.99 standalone
ASUS ROG Strix B850-G Gaming WiFi	White micro-ATX build	Four M.2, Wi-Fi 7, 2.5GbE, 20Gbps USB-C, PCIe 5.0 x16	ASUS listed $259.99 standalone; bundle was $1,059.99
ASUS ROG Crosshair X870E Hero	Storage, USB4, and expansion-heavy build	Five M.2, SlimSAS, dual USB4, 5GbE + 2.5GbE, Wi-Fi 7	ASUS listed $569.99 standalone; bundle was $1,599.99

The standalone MSI price is a dated Newegg feed snapshot. The ASUS figures came from the official product-page offers captured on August 18. The bundle figures are current retailer snapshots described later. Check the live number before ordering.

The rule that prevents motherboard overspending

Buy the cheapest well-built board that has the ports you will use. Then verify its slot and lane map. Write those requirements down before opening retailer tabs; otherwise every extra feature looks useful in isolation.

The Ryzen 7 9800X3D is an eight-core, 120W AM5 processor. A decent B850 board already supplies ample CPU power. Moving to X870 or X870E changes the connectivity floor and lane layout; it does not add gaming frames by itself.

I would reject a board for:

no BIOS Flashback on an expensive build
weak rear I/O for the devices you own
only gigabit Ethernet when faster networking matters
a lane-sharing rule that disables a card or drive you plan to install
too few M.2 slots for the build’s life
a price that approaches premium X870E territory without premium I/O

A lower chipset rung does not disqualify a board. A missing port or broken lane plan does.

1. MSI B850 Tomahawk Max WiFi is the default

The B850 Tomahawk Max WiFi is the board I would put under a 9800X3D gaming system unless the build brief names a reason to move. That reason should be concrete: a smaller white case, five NVMe drives, USB4 peripherals, or an add-in-card layout this board cannot serve.

The exact Newegg row lists:

ATX form factor
B850 chipset and AM5 socket
PCIe 5.0 x16
a Gen5 M.2 slot
Wi-Fi 7
5GbE
four DDR5 slots
four SATA ports
an 80A smart-power-stage design

That is the useful part of a modern high-end platform without a flagship tax. The August 17 feed captured $209.99 against a $229.99 regular field. Even if the live price moves, the board belongs in the low-$200 class. A $500 board serves a different build.

There is one layout caveat in the retailer specification: the lower PCIe 4.0 x4-length slot drops to x2 when M.2_3 is populated. If you plan to run a fast capture card, storage adapter, or 10GbE NIC there, read the manual before filling every M.2 slot. Gaming builds with one GPU will rarely care. Hybrid workstation and homelab builds can care immediately.

For a gaming tower with one GPU, two or three NVMe drives, and onboard networking, this is the complete answer.

2. ROG Strix B850-G is the white micro-ATX pick

The B850-G exists for a different build. It compresses a premium-looking white AM5 platform into micro-ATX without stripping the storage and rear I/O that usually disappear first.

ASUS specifies:

micro-ATX
14+2+1 power stages
PCIe 5.0 x16
four M.2 slots, including one Gen5 slot
Wi-Fi 7
Intel 2.5GbE
ten rear USB ports, led by 20Gbps Type-C
BIOS Flashback and Clear CMOS buttons

The fourth M.2 slot sits on the underside, which matters for access and cooling. Two SATA ports are also lean for anyone reusing several 2.5-inch drives. Those layout costs should be in the case plan. Install the underside SSD before the board goes into the chassis; discovering it later turns a two-minute upgrade into a teardown.

ASUS’s page listed $259.99 at capture. That premium over the MSI buys a smaller white board and its particular I/O arrangement. It does not buy a faster 9800X3D.

Search NeweggLink checked 2026-08-18

3. Crosshair X870E Hero is for expansion

The Crosshair X870E Hero is not the “best gaming” choice. It is the choice for a system that needs to behave like a workstation while keeping an X3D gaming CPU.

Its reason to exist is the I/O map:

five M.2 slots, three of them Gen5 with a Ryzen 9000 or 7000 processor
SlimSAS plus four SATA ports
two USB4 40Gbps rear ports
eight additional 10Gbps rear USB ports
5GbE and 2.5GbE
Wi-Fi 7
two full-length CPU-connected slots with configurable lane sharing
onboard Q-Code, start controls, BIOS Flashback, and Clear CMOS

The lane-sharing rules deserve attention. Populate the second and third CPU-connected M.2 slots and the primary graphics slot can fall to x8 while the second full-length slot changes or disables. That is normal on a feature-dense desktop platform, but it means the installation order needs a plan. Sketch the final drive and card map first. Buying five slots is useless if populating the wrong two breaks the slot you bought the board to gain.

ASUS listed $569.99 at capture. Spend that only when the five-drive layout, USB4, dual wired networking, or slot flexibility replaces hardware you would otherwise add. A single-GPU gaming PC with two drives does not need it.

Search NeweggLink checked 2026-08-18

B850 vs X870 vs X870E for the 9800X3D

Chipset class	Buy it when	Do not buy it for
B850	One GPU, normal NVMe count, gaming-first value	More FPS from the CPU
X870	You want USB4 and a stronger modern-I/O baseline	A belief that “X” means faster games
X870E	You need more high-speed expansion and can map the lanes	One GPU, two drives, and no add-in cards

AMD’s AM5 chipset table is the right starting point, but a model’s manual is the final authority. Two boards with the same chipset can expose different slots and controllers. Their sharing rules can differ too.

That is why the shortlist crosses chipset tiers. It follows build requirements.

Are the CPU bundles worth it?

The August feed contained several Ryzen 7 9800X3D motherboard bundles. Three illustrate why “bundle” is not a synonym for “deal.”

Bundle	Aug. 17 snapshot	Rendered seller check, Aug. 18	What to verify
Sapphire NITRO+ B850M + 9800X3D	$969.99	TECH EDGE; new; ships from China; not fulfilled by Newegg	Manufacturer warranty flag was false; returns were non-replaceable
ASUS ROG Strix B850-G + 9800X3D	$1,059.99	TECH EDGE; new; ships from China; not fulfilled by Newegg	Manufacturer warranty flag was true; still compare return freight and delivery
ASUS Crosshair X870E Hero + 9800X3D	$1,599.99	TECH EDGE; new; ships from China; not fulfilled by Newegg	Manufacturer warranty flag was true; the premium only works if you need the board

The seller was rated 4.6/5 over 39 reviews in the prior 12 months and marked Top Rated in the embedded listing data at capture. That is useful context. It is not the same purchase path as a direct Newegg item. A heavy motherboard-and-CPU return to China can consume the paper discount in freight and delay. It also adds transit risk.

Price the CPU and board separately first. Newegg’s exact 9800X3D row was $479 in the same feed. Add the $209.99 MSI board and the parts total is $688.99 before tax. A $969.99 micro-ATX bundle therefore needs to justify roughly $281 through a different board, availability, or terms. The Crosshair bundle is a specialist purchase rather than a value shortcut.

If you still want a bundle, use the current searches below and inspect the exact seller block before payment.

Search NeweggLink checked 2026-08-18

What about B650 and X670?

You do not need to replace a good AM5 board merely because B850 and X870 exist.

If you already own B650, B650E, X670, or X670E, check the manufacturer’s 9800X3D BIOS support and the ports you need. A supported existing board is usually the value winner. The ROG Strix B650-A review covers one real example of a B650 board running an X3D system with ample power delivery.

Before a BIOS update, back up important data and do not interrupt power during the flash. Use BIOS Flashback when the board supports it and the installed CPU cannot boot the current firmware.

This page covers a new board purchase. A working compatible platform should stay in service.

RAM, cooling, and the rest of the build

Use two DDR5 modules. DDR5-6000 with an AMD EXPO profile is the low-drama target; the DDR5 buying guide explains why a larger advertised number is not automatically a better AM5 result. For the purchase itself, use the open RAM price index: its August 18 capture reviewed 583 listings, still found only three of 12 tracked kits that cleared the direct-retailer rules, and put the cheapest qualifying 32GB observation at $459.99. The gate remains closed, so treat the table as dated offers rather than a broad market average.

The 9800X3D does not include a cooler. Board selection should therefore leave room in the case and budget for the cooling hardware you want. The board does not need a giant VRM heatsink to survive this CPU, but the case still needs airflow across the socket, memory, SSD heatsinks, and graphics card. Header placement matters here: count pump and fan headers against the actual radiator and case layout, rather than assuming a premium board has one in the convenient corner.

One build can overturn the entire default. Imagine a 9800X3D workstation with an RTX 5080, three Gen5 scratch drives, two more archive SSDs, a capture card, 10GbE today, and a USB4 RAID enclosure already on the desk. The Crosshair’s price is suddenly easier to defend because one board replaces an add-in network card, a storage adapter, and a Thunderbolt-style expansion plan. Remove those devices and the logic collapses back to B850. That is the standard: every premium interface should displace another cost or solve a named constraint. The workstation case can defend the X870E premium because its five-drive map, USB4 enclosure, faster wired links, debug controls, and second expansion slot replace a pile of adapters while keeping the build coherent; a one-GPU gaming tower with two SSDs receives none of that value, even though both machines use the same processor and can post the same frame rate. Run the same test in reverse before paying: remove USB4, the fifth drive, the second network link, and the extra card from the parts plan; if the system still works exactly as intended, the premium board has lost every job that made it rational and the B850 choice is stronger.

Finally, map the whole build before checkout:

exact case form factor
GPU thickness and slot obstruction
number of M.2 and SATA drives
front USB-C header requirement
wired network speed
add-in cards now and later
fan and pump-header count

The PC Builder catches the basic socket and form-factor problems. Its open 126-part compatibility dataset exposes the source and last-verified date behind each supported row. The board manual catches the lane-sharing rules that a category-level dataset cannot.

The shortest honest recommendation

Buy the MSI B850 Tomahawk Max WiFi for a normal ATX 9800X3D gaming build.

Buy the ROG Strix B850-G when the machine must be white and micro-ATX.

Buy the Crosshair X870E Hero only when five M.2 slots, USB4, dual wired networking, or its expansion controls are already part of the plan.

Anything beyond that is paying for a feature list you have not assigned a job.

Best RTX 5080 Prebuilt Gaming PCs (2026)

LK Wood IV — Tue, 18 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-18 · 13 min read · St. Louis County, MO

The three picks at a glance

All three finalists use the same performance core: Ryzen 7 9800X3D, GeForce RTX 5080 16GB, 32GB DDR5, and a 2TB NVMe SSD. The table therefore ranks what usually stays hidden in a prebuilt listing.

Pick	Why it made the list	Disclosed power supply	Newegg feed snapshot, Aug. 17
ABS Kaze II Ruby	Best disclosed parts list and power hardware	Gamdias HELIOS P2-1000G, 1000W Gold	$2,939.99
Andromeda Insights V3 Ultra 50	Best value; explicitly lists DDR5-6000 and an 850W Gold supply	850W Gold, brand not stated	$2,799.99
Acer Nitro UD.P02AA.070	Brand-name alternative with liquid cooling	850W, efficiency and model not stated	$3,299.99

Those prices are dated retailer-feed snapshots. The exact Newegg pages still resolved to the matching item on August 18, and all three pages showed Newegg as both seller and shipper at capture. Inventory can move before this page does.

How I ranked the systems

I started with a hard floor, then let disclosed component quality break the tie. A product page that names the PSU model, memory arrangement, storage generation, board, and seller path can justify a modest premium because each disclosed field removes a return-window investigation; a page that repeats only the CPU and GPU cannot.

RTX 5080 16GB and Ryzen 7 9800X3D. A cheaper processor can still run a 5080, but it is less hardware at this price. Every finalist uses AMD’s eight-core X3D chip.
32GB DDR5 and 2TB NVMe. A $3,000 gaming PC should not arrive with 16GB or a cramped 1TB system drive.
At least 850W. NVIDIA lists 850W minimum system power for the 360W RTX 5080. The full RTX 50-series PSU guide explains when 1000W becomes the better buy.
A listing that names the weak links. PSU model, memory speed, motherboard, cooler, seller, and warranty matter. Silence is a risk, not a premium feature.
The title, item number, and destination had to agree. I discarded feed rows whose product name and Newegg URL described different hardware.

RGB earned zero points. A giant discount badge against a price the system may never have sold for earned zero too.

1. ABS Kaze II Ruby has the strongest disclosed parts list

The Kaze II Ruby wins because its parts list answers the most expensive hidden question. Newegg names the power supply as a Gamdias HELIOS P2-1000G 1000W 80 Plus Gold unit. That changes the decision: the other two finalists list capacity, but they never identify the complete model.

The rest is the right shape for a high-end gaming system:

Ryzen 7 9800X3D
RTX 5080 16GB
32GB DDR5
2TB PCIe NVMe SSD
Wi-Fi 6
Windows 11 Home

The August 17 feed showed $2,939.99, down from a listed $3,499.99 regular figure. I care more about the $2,939.99 checkout number than the size of that markdown. The flashy percentage badge can disappear tomorrow; the named power supply is still the hardware inside the case.

There are still three checks to make. Confirm the 32GB arrives as two modules, identify the motherboard, and read the current warranty and return language. A named PSU does not make every undisclosed part disappear. It does make this the easiest system to approve. If the checkout configuration swaps any of those fields, stop and re-price the machine.

2. Andromeda V3 Ultra 50 is the value pick

The Andromeda was the least expensive qualified system in the feed at $2,799.99. It also discloses more memory detail than the other listings: 32GB of DDR5-6000. The 2TB drive is described as Gen4, and the power supply is rated 850W Gold.

That is a strong specification sheet for $140 less than the ABS. The trade is confidence around the power supply. “850W Gold” tells you the capacity and efficiency tier; it does not identify the platform, protections, cable, or warranty. NVIDIA’s 850W floor means the capacity is sufficient. The missing model is why this system finishes second. Ask for the exact unit before the return window closes; a photo of the side label settles it in seconds.

The exact page showed the matching Andromeda title. Newegg handled both the sale and shipment from the United States when checked. That removes the marketplace ambiguity that sinks many cheaper-looking results.

Buy this one when the price gap matters and the listing or support team can provide the exact PSU and memory configuration before the return window closes.

Check NeweggLink checked 2026-08-18

3. Acer Nitro is the brand-name alternative

Acer’s Nitro UD.P02AA.070 keeps the same core specification and adds liquid CPU cooling. The listing names a Ryzen 7 9800X3D, RTX 5080 16GB, 32GB DDR5, 2TB PCIe NVMe SSD, and an 850W power supply.

It also asks the most. The feed captured $3,299.99, which is $360 above the ABS and $500 above the Andromeda. The listing does not name the PSU model or efficiency certification, and it specifies gigabit Ethernet rather than a faster wired interface.

That does not make the Acer a bad machine. It makes the premium hard to defend from the published parts list alone. Choose it if the exact Acer service package, local availability, or chassis design has value to you. On hardware disclosure per dollar, it ranks third. At this price, brand familiarity needs to arrive with a better support path, not merely a familiar badge.

Check NeweggLink checked 2026-08-18

What I rejected

The live search results contain dozens of RTX 5080 systems. Most fail for one of five reasons.

A lower-tier CPU at the same system price

A Core i7-14700F or Ryzen 7 9700X can be a good processor. It does not belong in a system priced beside these 9800X3D builds unless the rest of the machine is materially better.

Sixteen gigabytes of system memory

That is an immediate upgrade on a new flagship PC. It also raises the chance of a single-module configuration. Thirty-two gigabytes is the floor here.

One terabyte of storage

Modern game libraries fill it quickly. A 2TB system drive is a modest requirement at this budget, and all three picks meet it.

A vague or undersized power supply

The RTX 5080’s official requirement is 850W system power. A listing below that floor is out. A listing that says only “1000W” without a model still needs investigation; wattage cannot tell you build quality.

Marketplace ambiguity

The product page must identify seller and fulfillment. It must also state the condition and warranty. The return path needs to be clear. A low price from an unknown seller can erase its savings with one freight return, and on a 40-pound glass-sided tower the expensive failure is rarely the missing five percent of benchmark performance; it is discovering after delivery that the power supply, memory layout, or warranty differs from the product tile while the only remedy is packing the entire machine again.

The price ceiling for a 32GB and 2TB build

My cutoff for this specification is roughly $3,500 before tax. Cross it, and I want a visible reason:

64GB instead of 32GB
4TB instead of 2TB
a premium factory-overclocked RTX 5080
a clearly better motherboard, PSU, and cooling stack
a service package worth buying

A basic 32GB/2TB system at $3,700 is too close to premium-custom pricing. It also gets uncomfortably close to the next GPU tier. If you are willing to assemble the machine, compare the full bill against the $2,500-class RTX 5080 build and load the same parts into the PC Builder.

What performance should you expect?

NVIDIA specifies the RTX 5080 with 10,752 CUDA cores, 16GB of GDDR7, a 360W total graphics power rating, and an 850W minimum system requirement. The Ryzen 7 9800X3D supplies eight Zen 5 cores and 96MB of L3 cache on AM5.

Those specifications put every finalist in the same broad performance class. Cooler design and the installed GPU model decide some of the small gaps, while power limits, BIOS behavior, and memory configuration decide the rest.

For a measured reference, the ROG Astral RTX 5080 OC review includes first-party 4K results and a 308-sample power log. The open bench dataset carries the underlying game and clock rows, plus thermal and power measurements, under CC BY 4.0. Use it as a picture of what one well-cooled premium 5080 did; an OEM card may hold different clocks.

The practical target is 4K gaming. At 1440p, a cheaper GPU can often deliver the experience without forcing the rest of the build into this price band. The 2026 4K GPU guide maps that break point. If your monitor is still 1440p/144Hz, spend against the display before paying for unused GPU headroom.

Here is the edge case that changes my answer. A buyer who keeps a PC for six years, moves from 1440p to a 4K OLED next spring, runs local models on the 16GB card, and refuses to replace parts mid-cycle can justify buying the 5080 tower before the current monitor demands it. That is a planned multi-use purchase, not a vague future-proofing claim.

There is measured evidence for the local-model half. On TechFuelHQ’s retail RTX 5080, the open Ollama throughput dataset recorded gpt-oss:20b fully GPU-resident at roughly 13.7–14.0 GiB and 187–190 decode tokens per second; the raw CSV is mirrored on Kaggle and Hugging Face. That does not benchmark image generation or prove every 16GB workload fits. It does show that a named local-AI role can be real rather than speculative.

The six-year plan has named workloads and a named display upgrade, with enough time for the premium to spread across several roles. Remove the 4K display and local workload, and the logic collapses: a gaming-only 1440p buyer is left with expensive capability no current screen or workflow can turn into visible value.

The 60-second checkout audit

Do this after clicking through and before payment.

Match the item number to the exact row in this guide.
Confirm Ryzen 7 9800X3D and RTX 5080 16GB in the selected configuration.
Look for two memory modules. If the page stays silent, ask or check immediately after delivery.
Confirm the PSU model and a native 12V-2x6 cable where possible.
Count open M.2 slots and accessible DIMM slots for future upgrades.
Read who sells it and who ships it.
Open the warranty and return terms.
Screenshot the final configuration and delivery promise.

If one of those fields changes, re-rank the system. The model name on the case matters less than the parts and terms attached to the exact SKU, because two towers wearing the same product-family badge can differ in the power supply and memory layout. They can also arrive with a different motherboard, SSD, cooler, seller, warranty, or delivery promise. Those details decide whether a prebuilt stays an easy purchase or becomes an expensive return. The exact-SKU check is the purchase: without it, a familiar family name can hide a lower-tier power supply, one memory module instead of two, a different motherboard, or a return path that turns a small discount into a freight bill after the tower is already in your house.

Best RTX 5090 Prebuilt Gaming PCs (2026)

LK Wood IV — Tue, 18 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-18 · 14 min read · St. Louis County, MO

The three picks at a glance

These systems share the expensive core: Ryzen 7 9800X3D, GeForce RTX 5090 32GB, 32GB DDR5, and 2TB of solid-state storage. The ranking turns on the platform around those parts and the price attached to the exact SKU.

Same GPU and CPU. Very different risk.

Pick	Why it made the list	Disclosed power and cooling	Live Newegg price, Aug. 18
Stormcraft Valkyrie	Best pick; most complete useful disclosure	1300W 80 Plus Gold, 360mm AIO	$5,599.99
Acer Nitro N80-181-UR19	Best value; same gaming core for $300 less	1200W, liquid cooling; PSU model not stated	$5,299.99
Thermaltake View 9890S	Premium white X870 alternative; not the value choice	1200W Gold ATX 3.0, Thermaltake 360mm AIO	$6,699.99

All three pages showed sold and shipped by Newegg when captured. These are live-page snapshots. Prices can move. Thermaltake is the important warning: its August 17 affiliate feed showed $6,090.99, but the rendered product page was $6,699.99 on August 18. The checkout page wins that disagreement.

How I ranked the systems

The full August 17 feed held four direct-catalog RTX 5090 desktops. Two Stormcraft rows used the same chassis and price with different processor platforms, so I narrowed the final comparison to the three Ryzen 7 9800X3D systems; holding the gaming CPU, GPU, memory capacity, and storage capacity steady exposes the platform differences instead of burying them under a changing processor.

I then scored the parts that can turn a $5,000-plus computer into a poor purchase:

Power path. NVIDIA rates the RTX 5090 at 575W and specifies 1000W required system power. A 1200W or 1300W supply is the right capacity class here, but capacity is only the start. The model, protections, and native GPU cable still need confirmation.
Memory configuration. Thirty-two gigabytes must be two modules. Acer and Stormcraft explicitly showed 16GB x 2 in the captured specifications.
Cooling and airflow. A 360mm AIO earns confidence only as a disclosed component, not as proof of low temperatures or noise. I have not tested these systems.
Storage and motherboard. A 2TB system drive is the floor. Gen4 detail and a named chipset make future expansion easier to judge.
Seller and price integrity. The item number, title, live price, seller, and shipper had to agree on the rendered page.

RGB, “AI powered,” and giant markdown badges earned nothing. Exact parts and a clean return path did.

1. Stormcraft Valkyrie is the best pick

The Valkyrie asks $300 more than Acer and gives a visible reason for most of that difference. Its product page names:

Ryzen 7 9800X3D
RTX 5090 32GB
32GB as two 16GB DDR5-6000 modules
2TB Gen4 NVMe SSD
AMD B850 motherboard
360mm AIO liquid cooler
seven ARGB fans
1300W 80 Plus Gold power supply

That is the strongest platform disclosure in the direct-retailer set. The 1300W capacity sits above the practical 1200W target in the RTX 50-series PSU guide, and the listing gives the memory speed, module count, storage generation, motherboard chipset, radiator size, and fan count. The page also showed Newegg as both seller and shipper.

Several identities remain hidden: “1300W 80 Plus Gold” does not name the PSU manufacturer or model, and the listing says component brands may vary, which means the exact graphics card, memory kit, SSD, board model, and supply can change within the stated specification. I cannot call those parts premium. The page still tells the buyer more than the others.

At $5,599.99, the Valkyrie is the best choice when you want the 5090 tier and would pay $300 to remove several expensive unknowns. Confirm those fields one final time before ordering.

2. Acer Nitro is the value pick

Acer’s N80-181-UR19 is the lowest-priced direct 9800X3D and RTX 5090 system in the captured feed and live pages. At $5,299.99, it is $300 below the Stormcraft and $1,400 below the Thermaltake.

The useful disclosures are better than the short feed title suggests:

Ryzen 7 9800X3D
RTX 5090 32GB
32GB DDR5 as 16GB x 2
2TB PCIe SSD
1200W power supply
liquid CPU cooling
Wi-Fi 6 and gigabit Ethernet

The 1200W capacity is appropriate. The weak point is identity. The page does not name the PSU model or efficiency certification, and its detailed table says only “Liquid Cooling” even though the title advertises a 240mm AIO. It also leaves the motherboard model and SSD generation unstated.

That makes Acer the value pick, with a plain trade: save $300 and accept less component identity, or pay Stormcraft for DDR5-6000, a named B850 chipset, Gen4 storage detail, a larger listed radiator, and another 100W of supply capacity. Choose Acer when the support channel, chassis, and saving matter more. Photograph the PSU label and memory modules after delivery, before the return window gets short.

Check NeweggLink checked 2026-08-18

3. Thermaltake View 9890S is the premium alternative

The View 9890S has the clearest named cooling and platform combination:

Ryzen 7 9800X3D
RTX 5090 32GB
32GB DDR5-6000
2TB NVMe SSD
AMD X870 chipset
Thermaltake 360mm ARGB AIO
1200W 80 Plus Gold ATX 3.0 power supply
Wi-Fi 7
white panoramic chassis

Those are real differences. X870, a named Thermaltake radiator, Wi-Fi 7, a white build, and a more explicit ATX 3.0 supply description can matter to a buyer who wants this exact design.

The price breaks the general recommendation: the live page showed $6,699.99, or $1,100 above Stormcraft and $1,400 above Acer, while the prior feed showed $6,090.99. At the live number, the premium buys appearance and platform detail rather than more GPU, CPU, memory, or storage capacity.

I would skip that premium for gaming performance. This system stays on the list as the distinct white X870 alternative. It does not compete for value at the captured price. If it falls near the Valkyrie, re-run the comparison.

Check NeweggLink checked 2026-08-18

Why these are 9800X3D systems

At this price, the processor should fit the job. The Ryzen 7 9800X3D is an eight-core, 16-thread, 120W AM5 processor with 96MB of L3 cache. It is the gaming-first choice in the captured direct-retailer set.

The feed also held a $5,599.99 Stormcraft Valkyrie with an Intel Core Ultra 7 270K Plus, a system that can make sense for a different workload mix but would blur this gaming comparison by changing the processor platform while every other finalist stays on the 9800X3D.

I kept the CPU constant on purpose. Once every row uses a 9800X3D and RTX 5090, the reader can compare the system rather than decoding two product categories at once.

What a $5,000-plus prebuilt must disclose

The expensive GPU cannot be permission for everything around it to become vague. A machine at this price should make its electrical and upgrade constraints easy to inspect before you pay, then easy to verify again when the box arrives. Two facts from this comparison show why the second check matters. Thermaltake’s live price had moved $609 above the prior feed snapshot. Stormcraft warns that component brands may vary inside the stated configuration. Save the checkout screenshot. When the box arrives, compare the delivered graphics card and power supply against the order. Check the memory module count and motherboard next. Finish with the SSD and cooler. Inspect the cabling before the return window gets short.

A native high-current power path

NVIDIA lists 575W total graphics power and 1000W required system power for the RTX 5090. A capacity label of 1200W or 1300W clears the first test. The exact PSU model and a native cable clear the second.

Avoid treating four adapter leads as a harmless visual issue. This is a high-current connection behind a large card. Confirm the cable type, seat it fully, and avoid a tight bend at the connector.

Two memory modules

The captured Acer and Stormcraft pages showed 16GB x 2. Thermaltake disclosed 32GB DDR5-6000 but did not expose the module count in the same table. Confirm two modules before accepting the configuration.

Thirty-two gigabytes is enough for gaming. The DDR5 buying guide covers capacity and timing tradeoffs if this tower will also be a 64GB creator or local-AI machine.

Storage that fits the price

Two terabytes is the floor at this tier. Stormcraft identifies its drive as Gen4. Acer says 2TB PCIe, while Thermaltake says 2TB NVMe. None of those capacity lines tells you controller, endurance, or sustained write behavior.

Identify the installed SSD after delivery and count the open M.2 slots. A $5,500 tower should not require replacing its only system drive just to add working space.

A motherboard and case you can expand

Stormcraft discloses B850. Thermaltake discloses X870. Acer leaves the board unnamed in the saved specification. The chipset will not create gaming frames. It does help define storage lanes and USB. It also tells you more about networking and future cards.

Case dimensions and slot clearance matter too. An RTX 5090 is not a small component. Confirm that the installed model has room to breathe and that adding another card or bottom-mounted fans will not choke it.

RTX 5090 or RTX 5080 prebuilt?

The RTX 5090 tier needs a named reason. Mine would be one of these:

maximum native or lightly upscaled 4K performance
a 4K high-refresh display that can expose the difference
32GB of VRAM for local AI, rendering, or creation
one machine serving both gaming and a GPU-heavy paid workload

If the computer is for ordinary 1440p gaming or 4K with DLSS, the best RTX 5080 prebuilt guide starts at $2,799.99 in the same dated retailer feed. The jump from that value pick to the least expensive 5090 system here was $2,500. That money can buy a serious display and a later GPU upgrade. It can also fund the memory and storage the system will use every day.

The RTX 5090 is faster. It is not automatically the better purchase. NVIDIA’s official specifications put the difference in plain terms: 32GB versus 16GB of GDDR7 and a 575W versus 360W power rating. The 2026 4K GPU guide places both cards in the wider buying ladder.

The price ceiling

My practical ceiling for this configuration is about $6,000 before tax. That means a 9800X3D, 32GB, 2TB, and an RTX 5090. Cross the line only when the premium buys something you can name.

Above that line, I want several of these:

64GB of memory
4TB or more of quality storage
an explicitly named premium RTX 5090 model
a named high-end power supply
a motherboard and networking stack worth the difference
a service package with measurable value
a chassis and cooling configuration you were already willing to buy separately

Thermaltake’s live $6,699.99 can be defended only by the buyer who already values its white panoramic design, X870 platform, Wi-Fi 7, named 360mm cooler, and ATX 3.0 power description. Those features do not make it $1,100 faster than Stormcraft.

The 60-second checkout audit

Do this after clicking through and before payment.

Match the item number to the exact system in this guide.
Confirm Ryzen 7 9800X3D, RTX 5090 32GB, 32GB DDR5, and 2TB storage.
Look for two memory modules and record their speed.
Identify the exact PSU model and native GPU cable.
Identify the graphics-card, motherboard, SSD, and cooler models.
Confirm who sells it and who ships it.
Open the warranty and return terms, including freight.
Check case clearance, open M.2 slots, and usable expansion slots.
Screenshot the final configuration, price, delivery date, and seller block.

If the configuration changes, the ranking changes with it. At this price, a family name is not a substitute for the exact hardware and terms you are buying.

Best Wi-Fi 7 Routers (2026): 3 Picks That Make Sense

LK Wood IV — Tue, 18 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-18 · 13 min read · St. Louis County, MO

Three picks at a glance

Choose the band layout first. Then count the ports. A giant aggregate speed number comes last because no single client receives the whole number printed on the box.

Pick	Best for	Radio layout	Useful wired I/O	Live price, Aug. 18
TP-Link Archer BE550 Pro	Best for most homes	Tri-band: 2.4 + 5 + 6GHz	1× 10G WAN, 4× 2.5G LAN	$229.99
ASUS RT-BE88U	Wired-first router and switch replacement	Dual-band: 2.4 + 5GHz; no 6GHz	10G SFP+, 10G WAN/LAN, 4× 2.5G, 4× 1G	$338.99
ASUS GT-BE98 Pro	Premium wireless capacity and dual-6GHz AiMesh	Quad-band: 2.4 + 5 + 6 + 6GHz	10G WAN/LAN, 10G LAN, 3× 2.5G LAN	$629.99

These are dated direct-listing prices. The exact pages resolved and showed the matching product in stock at capture, but the seller and price can move before this article does.

The decision before the product

This page assumes you have already decided Wi-Fi 7 is worth buying. If that question is still open, start with Wi-Fi 7 for the home network and homelab. It covers real throughput, MLO, client support, and the cases where Wi-Fi 6E should stay in service.

For the purchase itself, write down four facts:

Does the router need 6GHz? If 320MHz channels are part of the plan, yes.
What feeds the router? Gigabit, 2.5Gbps, 5Gbps, or 10Gbps internet changes the WAN requirement.
What sits behind it? A NAS, multi-gig switch, or wired gaming PCs decide the LAN ports.
Is one access point enough? A large or difficult house may need mesh instead of a more expensive standalone box.

The best router is the least expensive one that serves those four constraints. The rest is unused radio inventory. A flagship only earns its place when the second 6GHz radio, extra 10G path, or denser wired switch replaces another box or fixes a measured bottleneck; without that job, the premium buys capacity that sits idle while the same phone and laptop behave much as they would on the midrange router.

1. TP-Link Archer BE550 Pro is the best pick

The Archer BE550 Pro is the rare midrange router whose wireless and wired sides match. TP-Link specifies three bands, including 6GHz, with 320MHz channels and MLO. The wired side has one 10Gbps WAN port and four 2.5Gbps LAN ports.

That combination matters more than the BE9700/BE9300 naming inconsistency between TP-Link and the retailer feed. A fast Wi-Fi client can reach a multi-gig NAS without being pinched through a gigabit LAN port. A 5Gbps fiber service can enter through the 10G WAN port. Four 2.5G LAN ports also remove the immediate need for a small multi-gig switch in many homes.

At $229.99, it sits where the existing technology guide said useful tri-band Wi-Fi 7 should sit: the low-to-mid $200s. It is $109 below the RT-BE88U and $400 below the GT-BE98 Pro.

I would still verify three details at checkout. Match BE550 Pro, not the nearby BE550 family name. Confirm the regional version. Then check that the phone, laptop, or desktop you expect to speed up supports 6GHz Wi-Fi 7; a router cannot add a radio to the client.

2. ASUS RT-BE88U is the wired-first exception

The RT-BE88U is an unusual recommendation because its strongest feature is also the reason many Wi-Fi 7 buyers should skip it.

ASUS calls it dual-band. The official specification and Newegg table show only 2.4GHz and 5GHz wireless. There is no 6GHz radio, so there are no 320MHz 6GHz channels. Put that fact above every marketing number.

The wired layout is excellent:

one 10G SFP+ port
one standard 10G WAN/LAN port
four 2.5G ports
four gigabit ports
WAN/LAN aggregation options

For a homelab or fiber gateway, that can replace both a consumer router and a separate multi-gig switch. The SFP+ port is especially useful when the existing core already speaks DAC or fiber. At $338.99, the additional $109 over TP-Link can be cheaper than buying an extra managed switch.

For a wireless-first buyer, the logic reverses. Spending more while losing 6GHz makes no sense when the reason for the upgrade is wide-channel Wi-Fi. This is the port-density pick. Nothing else.

Check NeweggLink checked 2026-08-18

3. ASUS GT-BE98 Pro is the flagship

The GT-BE98 Pro carries four radios: 2.4GHz and 5GHz plus two separate 6GHz bands. ASUS pairs that with 320MHz support, one 10G WAN/LAN port, another 10G LAN port, three 2.5G LAN ports, plus AiMesh.

The second 6GHz radio is the feature that can justify the price. In an AiMesh deployment, one 6GHz band can carry wireless backhaul while the other serves clients. In a dense single-router deployment, the extra radio can divide high-end clients instead of placing them all on one 6GHz channel set.

Most homes will never turn that capability into a visible result. A single laptop cannot consume four bands. A gigabit internet plan cannot saturate the wired uplink. If the second 6GHz radio has no backhaul or client-density job, the $629.99 price is a $400 premium for idle capacity.

Buy it for a named topology: dual-6GHz AiMesh, multiple current Wi-Fi 7 clients, 10G core networking, or a flagship gaming network where cost is secondary. The GT-BE98 Pro is the strongest wireless platform here. It is not the default.

Check NeweggLink checked 2026-08-18

Why 6GHz changes the ranking

Wi-Fi 7 features are not one indivisible package. MLO and 4K-QAM can operate without 6GHz. The headline 320MHz channels cannot; in the United States they live in the 6GHz band.

That creates three product classes:

Class	What it gives you	What it misses
Dual-band Wi-Fi 7	MLO/4K-QAM on 2.4 and 5GHz, often strong wired I/O	6GHz and 320MHz channels
Tri-band Wi-Fi 7	The full mainstream feature set: 2.4, 5, 6GHz	A dedicated second 6GHz backhaul/client radio
Quad-band dual-6GHz	Extra capacity or dedicated 6GHz mesh backhaul	Value, unless the topology uses it

This is why TP-Link wins and ASUS RT-BE88U stays a specialist. The Archer delivers the feature most buyers mean when they say “upgrade to Wi-Fi 7.” The RT-BE88U delivers a different thing: a serious wired edge with a current-generation 5GHz radio.

Port topology beats a 30Gbps box number

Router marketing adds every radio’s theoretical maximum and prints the sum. That number is access-point capacity under ideal conditions. It is not a laptop speed test.

Read the physical ports instead:

Archer BE550 Pro: cleanest 10G-WAN-to-2.5G-LAN layout.
RT-BE88U: best wired density and the only SFP+ option here.
GT-BE98 Pro: two 10G-class paths plus three 2.5G LAN ports.

For a NAS and workstation, map the whole chain. A 10G router feeding a gigabit switch is still a gigabit network. A Wi-Fi 7 access point wired back through 1GbE is still limited to one gigabit of backhaul. The 2.5GbE versus 10GbE guide explains when the next wired tier pays off.

Standalone router or mesh?

These picks are standalone routers. That is deliberate. A mesh comparison needs node count and backhaul radio first; after that come wired backhaul speed, placement, and total-kit price. Mixing a three-pack Orbi or Deco kit into this table would create the appearance of choice while comparing different products.

Choose standalone when:

the router can sit near the center of the usable space
one access point already covers the home
Ethernet can feed a separate access point later

Choose mesh when:

floors, dense walls, or distance create repeatable dead zones
one central location cannot cover the house
you can wire at least the main satellite with 2.5GbE or faster

A larger antenna count does not repair a bad access-point location. Spend on topology before flagship hardware. Picture a two-story house with 5Gbps fiber, one wired office, a 10GbE NAS in the basement, and two Wi-Fi 7 laptops upstairs: the Archer serves the wireless upgrade and four 2.5G rooms cleanly; the RT-BE88U earns its premium only if its SFP+ and extra wired ports replace a switch; the GT-BE98 Pro earns its premium only if a second 6GHz radio carries mesh backhaul or a dense client group. The exercise also exposes the mesh question before checkout: if the upstairs devices remain weak because the access point is badly placed, buy a second wired access point or a mesh node rather than paying for a larger standalone router and hoping one box defeats the floor plan.

Do not upgrade to solve a fault

A router that disconnects clients, reboots, or loses WAN under load may need replacement. It may also have a channel, firmware, heat, power, or ISP problem. Work through Wi-Fi that keeps disconnecting before using a new wireless generation as a repair strategy.

The same rule applies to speed. Test a wired client first. If Ethernet is slow, the radio is innocent.

The 60-second checkout audit

Match the exact model and item number.
Count the bands. Look for 6GHz explicitly.
Confirm the WAN port speed and whether it can become LAN.
Count 10G, 2.5G, and 1G LAN ports separately.
Check whether your clients support Wi-Fi 7 and 6GHz.
Decide standalone versus mesh before ordering.
Confirm seller, warranty, return window, and regional version.
Screenshot the final price and configuration.

For most buyers, the answer remains the Archer BE550 Pro. It buys the radio that makes Wi-Fi 7 different and the ports that keep it from being trapped behind gigabit.

RTX 5090 vs RTX 5080 (2026): Which One Should You Buy?

LK Wood IV — Tue, 18 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-18 · 15 min read · St. Louis County, MO

The decision in one table

The RTX 5090 wins every absolute-performance question. The RTX 5080 wins the purchase question for most gamers. The exception is a buyer whose current game, render, model, or paid workflow already reaches the 16GB boundary or whose display can turn the 5090’s extra native-4K frame rate into something visible; in that case, the larger card solves a named limit rather than serving as expensive insurance.

Decision	RTX 5080	RTX 5090	Winner
4K gaming with DLSS	Strong, measured and playable	Faster	RTX 5080 value
Maximum native 4K	Compromises remain in the hardest titles	Fastest tier	RTX 5090
VRAM	16GB GDDR7	32GB GDDR7	RTX 5090
Card power	360W reference TGP	575W reference TGP	RTX 5080
Required system power	850W	1000W	RTX 5080
Local AI that fits inside 16GB	Already capable	Faster/roomier, but unmeasured here	RTX 5080 value
Workloads that exceed 16GB	Spill or fail	32GB headroom	RTX 5090
Most gaming builds	Rational ceiling	Halo purchase	RTX 5080

Current direct-retailer example

Launch MSRP is useful history. It is not the number buyers face today.

Exact card	What the listing disclosed	Live price, Aug. 18
GIGABYTE WINDFORCE RTX 5080 16GB	304mm long, 2.5 slots, 850W recommended PSU	$1,399.99
ASUS ROG Astral RTX 5090 32GB	14.1 inches, 3.8 slots, 1000W recommended PSU	$4,829.99

Both pages showed sold and shipped by Newegg at capture. The 5090 example cost 3.45 times as much. This is not an apples-to-apples cooler comparison: ROG Astral is a premium flagship board, while WINDFORCE is a simpler RTX 5080. It is still a real checkout comparison, and it shows why MSRP-only advice fails.

Specifications that matter

Specification	RTX 5080	RTX 5090	Difference
CUDA cores	10,752	21,760	+11,008
VRAM	16GB GDDR7	32GB GDDR7	2× capacity
Memory interface	256-bit	512-bit	2× width
Total graphics power	360W	575W	+215W
Required system power	850W	1000W	+150W

The core count is not a frame-rate equation. Games do not scale one-for-one with CUDA cores, and CPU limits, memory behavior, ray tracing, and engine design change the gap. The capacity and power differences are literal. They shape what fits in VRAM, which supply belongs in the system, and how much heat the case must move.

How much faster is the RTX 5090?

Two credible suites answer this in different shapes.

GamersNexus measured the RTX 5090 30% to 68.9% ahead of the RTX 5080 at 4K, depending on the game, with results commonly in the 45% to 55% range. That wide spread is the honest result. A single title can land near 30%. Another can approach 70%.

TechPowerUp’s combined 3840×2160 raster chart put the RTX 5090 at 152% of the RTX 5080’s performance, a 52% suite-level lead. That aligns with the middle of the GamersNexus range while using a different game list and aggregation method.

The safe buying number is therefore not “the 5090 is always 50% faster.” It is:

expect a large 4K lead
expect the exact lead to move by title
do not pay for the maximum result unless your own games resemble the workloads that produce it

At 1440p, CPU limits shrink the value of the larger GPU. If the display is 1440p, the RTX 5090 is usually an expensive way to wait on the processor.

What the RTX 5080 already does at 4K

TechFuelHQ owns and measures an ASUS ROG Astral RTX 5080 OC. The open bench dataset publishes raw values with the method and correction history under CC BY 4.0.

Measured 4K results include:

Workload	Average FPS	1% low
Cyberpunk 2077 Ultra raster	58	49
Cyberpunk RT Ultra, DLSS Quality	50	41
Cyberpunk Path Tracing, native	19	15
Alan Wake 2 RT, DLSS Quality	49	38
Black Myth Wukong Cinematic	34	27

The card needs help in the hardest path-traced workload. That is where DLSS 4 changes the buying decision. On the same system, Cyberpunk 4K path tracing measured:

Mode	Output FPS	PC latency
Native path tracing	19	95ms
DLSS Quality, no frame generation	40	45ms
DLSS Quality + MFG 2×	90	55ms
DLSS Quality + MFG 4×	135	62ms

If those techniques are acceptable, the RTX 5080 is already a serious 4K card. The RTX 5090 buys more native headroom and a higher starting frame rate. It does not make the RTX 5080 incapable.

The 16GB versus 32GB decision

For gaming, 16GB is the practical high-end capacity today. The first-party 4K runs above fit and complete on the RTX 5080. Buying 32GB solely because a future game might need it is weak evidence.

For work, capacity can become binary. A render scene, local model, image batch, or timeline either fits in VRAM or it does not. Once the workload crosses 16GB, the RTX 5090’s performance advantage is no longer just frames per second. It can keep work on the GPU that the 5080 must spill, reduce, or refuse.

Name the workload before paying:

What is the current peak VRAM allocation?
Does lowering batch size destroy throughput?
Does CPU/RAM offload create an unacceptable delay?
Does the extra GPU memory replace a second card, cloud bill, or work interruption?

If there is no measured 16GB problem, the 32GB answer is insurance at flagship pricing.

Local AI: use measured data, not parameter-count folklore

The RTX 5080 local LLM throughput dataset is measured on the same retail card and mirrored on Kaggle and Hugging Face. It shows what 16GB can already do:

gpt-oss:20b MXFP4: 187–190 decode tokens/second
resident VRAM: roughly 13.7–14.0 GiB
Qwen 2.5 14B Q4_K_M: 94–97 tok/s
Qwen 2.5 7B Q4_K_M: 177–180 tok/s

This site has no first-party RTX 5090 AI result, so I will not invent a speed multiplier. The grounded claim is capacity: 32GB gives room for larger fully resident models, longer contexts, image work, plus larger batches. The grounded counterclaim is equally important: 16GB is already enough for fast interactive use on several useful models.

Buy the 5090 for AI when a workload you run now exceeds the 5080’s capacity. Buy the 5080 when your actual models fit.

Power, case, and the rest of the system

The RTX 5090 adds 215W of reference board power. That changes more than the electric bill.

NVIDIA specifies 850W required system power for the RTX 5080 and 1000W for the RTX 5090. TechFuelHQ’s full RTX 50-series PSU guide treats 1200W as the practical high-end 5090 target once a powerful processor and factory-overclocked board enter the build.

Physical size follows the same pattern in the live examples:

GIGABYTE WINDFORCE RTX 5080: 304mm, 2.5 slots
ASUS ROG Astral RTX 5090: 14.1 inches, 3.8 slots

That can determine case choice, front-radiator clearance, lower-slot access, GPU support, and cable bend radius. The GPU price is only the first system cost.

Price-to-performance without fake precision

Using TechPowerUp’s 52% combined 4K raster lead and the two live listings above:

performance multiplier: about 1.52×
price multiplier: about 3.45×

That does not produce a universal “value score.” The cards are different AIB tiers, and the RTX 5090 also buys double the VRAM. It does show the shape of the purchase: live retail asks for far more money than the gaming-performance increase alone returns.

The RTX 5090 can still be the cheaper business tool when its 32GB capacity replaces cloud GPU time, cuts a render queue, or prevents an out-of-memory failure. Put a number on that benefit before paying: if the larger card saves four billable hours each week, avoids a recurring cloud instance, and keeps a current scene fully resident, the purchase has three measurable payback paths; if it only raises a benchmark score, gaming receives none of that accounting benefit.

Buy the RTX 5080 if

the system is primarily for gaming
DLSS Quality and frame generation are acceptable at 4K
current workloads fit inside 16GB
you want an 850W-class build with easier case fit
the 5090 price premium would delay the monitor, storage, or next upgrade

Buy the RTX 5090 if

maximum native or lightly upscaled 4K performance is the requirement
32GB solves a measured memory-capacity problem
rendering, AI, or creation time has direct financial value
the larger PSU, case, cooling, and card price are already budgeted
money-no-object performance is itself the goal

The first list describes most buyers. The second describes a smaller group with better reasons, and the difference should survive a simple counterfactual: if the paid workload, 32GB allocation, or native-4K display disappeared tomorrow, would the rest of the purchase still justify a card that costs several thousand dollars more and forces a larger power and cooling envelope?

Complete system or card?

If you want the GPU inside a ready-to-run tower, compare the best RTX 5080 prebuilts and best RTX 5090 prebuilts. Those guides rank power delivery and memory layout, then check storage, seller, and warranty details that disappear when a listing talks only about the GPU.

For the card alone, confirm the exact item and dimensions, then verify the recommended supply, seller, warranty, and return terms. A GPU family name is not the product in your cart.

Monitor Flickering? Use Task Manager to Find the Cause

LK Wood IV — Mon, 17 Aug 2026 00:00:00 -0500

By LK Wood IV · Published August 17, 2026 · St. Louis, Missouri

A flickering monitor is not one fault. It can be Windows repainting the desktop through a bad driver, one incompatible app flashing while the rest of the display is stable, a video cable losing the signal, an unstable power source, or variable refresh rate making dark scenes pulse.

That is why the usual list of ten random fixes wastes time. The order matters. I start with Task Manager, because Microsoft’s own procedure gives the cleanest Windows-side split: if Task Manager flickers with everything else, the display driver is the likely cause; if Task Manager stays stable while the rest flickers, an app is the likely cause.

First, name the symptom. A brief loss of the entire picture is a blackout, so use the monitor-keeps-going-black guide. A fixed vertical or horizontal band belongs in the lines-on-monitor guide. A trail behind motion is monitor ghosting. This page is for the image or brightness visibly pulsing while the picture remains on-screen.

Do not mix them.

The 30-second split

Wait until the flicker is visible, then press Ctrl + Shift + Esc to open Task Manager.

What flickers?	Start here	What it rules toward
Task Manager and the rest of Windows	Display driver	Update, roll back, or reinstall the driver
Everything except Task Manager	One incompatible app	Update or uninstall the app that triggers it
The monitor’s own menu or no-signal box	Monitor or power source	Cable-independent panel, board, or outlet problem
Only a dark game or loading screen with VRR on	G-Sync / FreeSync / Adaptive Sync	Frame-time and VRR-range tuning
Only at a high refresh rate or resolution	Cable, port, adapter, or bandwidth	Test a lower rate and a known-good connection

Microsoft’s screen-flickering procedure is explicit. Task Manager flickering with the screen points to the display driver. A stable Task Manager points to an incompatible app. That isolates the Windows side. The monitor still needs its own test.

One test creates two branches.

Open the monitor’s on-screen menu with its physical button or joystick while the flicker is happening. That menu is drawn by the monitor, not by Windows.

The menu is stable: Samsung’s diagnostic boundary points away from monitor service. Keep working the PC, cable, port, and refresh-rate steps below.
The menu flickers too: disconnect the video cable so the monitor shows its own no-signal message. If that also flickers, the PC is no longer involved. Test the monitor’s power source, then the monitor itself.

Samsung uses the same boundary in its monitor flicker troubleshooting. A clean menu or error message means the monitor does not need service; the connected device or cable is causing the issue. Flicker across those internal elements keeps the monitor side under suspicion.

Step 1: Reset the graphics driver

Press Windows key + Ctrl + Shift + B.

Windows briefly blanks or redraws the screen while it resets the graphics driver. Microsoft says the shortcut may fix the issue. A stable picture afterward is useful evidence for the Windows display path, but it is not proof that the monitor panel is healthy.

Do not treat the shortcut as a permanent repair. It restarts the driver; it does not fix why the driver became unstable.

If the flicker returns:

Open Device Manager.
Expand Display adapters.
If the problem started immediately after a driver update, open the adapter’s Properties → Driver tab and use Roll Back Driver when available.
If the driver is old, update it from NVIDIA, AMD, Intel, or the laptop manufacturer.
If updates and rollback both fail, uninstall the display adapter and let Windows reinstall it, or use the clean-install sequence in the GPU driver crash guide.

The timing decides whether update or rollback comes first. A driver that started flickering right after an update is not fixed by installing the same update again.

Step 2: If Task Manager is stable, find the app

When Task Manager stays solid while another window or the rest of the desktop flickers, Microsoft points at an incompatible app.

Do not reinstall the whole graphics stack yet. Find the smallest repeatable trigger:

Does it begin only when a browser opens?
Only when Discord, Steam, an overlay, capture software, or a remote-desktop app is visible?
Only while resizing a specific window?
Does closing that app stop the flicker immediately?

Update the app first. If it is already current, uninstall it, restart, and test before reinstalling. That gives you an actual control: same display driver, same monitor, app absent.

Older or incompatible Windows programs can show flickering windows even when the desktop is otherwise healthy. If one program is the trigger, changing the monitor cable will not repair it.

Step 3: Work the connection and power path

Samsung’s current monitor guidance puts the practical hardware-side suspects together: a loose or damaged cable, faulty power, high-current appliances on the same circuit, outdated drivers, and the computer’s refresh-rate setting.

Work these in order:

Reseat both ends of the video cable. Check for a crushed section, sharp bend, loose latch, or damaged connector.
Bypass the extras. Remove the dock, KVM, splitter, capture device, and adapter. Connect the PC directly to the monitor.
Try another port. Move to another output on the graphics card and another input on the monitor.
Try a known-good cable. Match its certification to the mode you run. The DisplayPort and HDMI bandwidth calculator shows whether the resolution, refresh rate, color depth, and chroma fit the connection.
Test another outlet. Plug the monitor directly into a different circuit as a control. Keep space heaters and other high-current loads off the same circuit during the test.

A new cable is evidence only if changing the cable changes the symptom. Buying three cables before running the Task Manager and monitor-menu tests is parts-cannon troubleshooting in a different form.

Change one thing only.

The trap is treating every flicker as a cable fault because the cable is visible and easy to replace, when a stable monitor menu, a Task Manager window that flickers with the desktop, and a symptom that began immediately after a driver update together make a far stronger case for the Windows display path than for the wire on your desk.

Step 4: Test the refresh rate

Open Settings → System → Display → Advanced display and confirm Windows is using a refresh rate the monitor supports.

As a diagnostic, temporarily drop from 144, 165, or 240 Hz to 60 Hz:

Flicker stops at 60 Hz: the original display mode is exposing a signal-path or monitor-timing problem. Test the cable, ports, adapters, and native mode separately before naming the failed part.
Flicker is unchanged: the refresh-rate ceiling was not the cause; return to the driver/app or monitor/power branch.

Do not leave a high-refresh monitor at 60 Hz. This is a short diagnostic control. Find the weak link, then restore the native rate with the correct cable and port.

Step 5: Only flickers in games? Test VRR

If the desktop is stable and the screen pulses in dark game scenes, loading screens, or menus, test G-Sync, FreeSync, or Adaptive Sync before replacing anything.

Variable refresh rate makes the monitor follow the GPU’s frame output. When frame times jump, the refresh rate jumps with them. KTC’s VRR flicker explanation describes the repeatable pattern: unstable frame rates force rapid refresh-rate changes, with the effect most visible in dark scenes or near the monitor’s VRR floor.

Run one controlled comparison:

Reproduce the flicker in the same scene.
Turn G-Sync, FreeSync, or Adaptive Sync off.
Replay the scene without changing anything else.

Use the exact same scene.

If the flicker disappears, the panel is not necessarily dying. Turn VRR back on and cap the frame rate to a level your PC can hold steadily. Also update the GPU driver and monitor firmware. The goal is steadier frame pacing, not a higher peak number.

Samsung also recommends disabling G-Sync or FreeSync as a flicker test on supported displays.

Step 6: When the monitor itself becomes the likely fault

Only then does the monitor side move to the top.

Suspect the display or its power board when:

its own on-screen menu flickers;
its no-signal message flickers with the video cable disconnected;
the same behavior survives a different cable, input, and source device;
a different wall outlet and power cord change nothing;
the flicker appears before Windows loads;
the panel brightness pulses even while displaying a static internal menu.

At that point, stop reinstalling drivers. If the monitor is under warranty, record a short video showing the flicker across the on-screen menu and request service. That evidence proves the symptom exists independently of the PC.

The fix order

Separate flicker from a full blackout, fixed line, or motion trail.
Open Task Manager: driver branch if it flickers, app branch if it does not.
Open the monitor menu: stable means upstream; flickering means monitor or power.
Reset the driver with Windows key + Ctrl + Shift + B.
Reseat and simplify the signal path: no dock, KVM, splitter, or adapter.
Test another cable, port, and outlet.
Drop the refresh rate temporarily to isolate bandwidth or timing.
For game-only flicker, toggle VRR and compare the same scene.
Request monitor service only after its own menu or no-signal image flickers.

That order stays reversible. More importantly, it gives each change a control. Prove which layer is unstable before replacing the layer below it.

Sources

Microsoft Support — Troubleshoot screen flickering in Windows — Task Manager split, graphics-driver reset, driver rollback/update/uninstall, and incompatible-app branch.
Samsung Support — Image is distorted, ghosted, or flickering on my Samsung monitor — cable, power-source, refresh-rate, driver, G-Sync/FreeSync, and monitor-menu controls.
KTC — What causes monitor flicker with VRR or Adaptive Sync — frame-time swings, rapid refresh-rate changes, dark-scene visibility, and the VRR-floor pattern.

Adding a User to the Docker Group Is Not a Convenience Setting (2026)

LK Wood IV — Sat, 15 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-15 · ~8 min read · St. Louis County, MO

Here is the command you came for:

sudo groupadd docker # only if the group does not exist yet
sudo usermod -aG docker $USER
# then log out and log back in

And here is the sentence that belongs next to it, which Docker puts in a Warning box on its own post-installation page and almost nobody repeats:

The docker group grants root-level privileges to the user.

Not “elevated access to Docker”. Root on the host.

Why it is root, concretely

The reason sudo is needed in the first place is architectural. Docker’s docs put it plainly: the daemon binds a Unix socket rather than a TCP port, that socket is owned by root, and the daemon itself always runs as root. Joining the docker group does not reduce what the daemon can do. It gives you write access to the socket that commands it.

The socket is the entire access-control model. Moby’s own systemd unit ships it as SocketUser=root, SocketGroup=docker, SocketMode=0660. There is no per-user authorization layer behind it. Anything that can write to that socket can ask the root daemon for anything.

So the escalation is not clever:

docker run --mount type=bind,src=/,dst=/host -it alpine sh

You are now root inside a container with the host’s entire filesystem at /host. Docker’s security page states it directly — the container can alter your host filesystem without any restriction. Edit /host/etc/shadow, drop a key in /host/root/.ssh/authorized_keys, whatever you like.

Notice what is absent. No --privileged. No sudo prompt. No password. No entry in the sudo log.

That last one is the part I find most under-discussed. sudo leaves a trail. Group membership does not.

Because Docker’s own docs frame it as convenience first. The section opens with the reasoning that if you don’t want to preface the docker command with sudo, you create a Unix group called docker and add users to it. The Warning box sits underneath that.

Read in order, the page teaches convenience and then qualifies it. Skimmed — which is how anyone with a broken build reads a post-install page — you get the command and miss the box. Docker clearly knows this happens, because they had to add a second and more explicit warning on the Windows side, where docker-users membership is described as equivalent to granting administrative privileges on the host. OWASP made not exposing the daemon socket rule number one of its Docker cheat sheet.

The warning exists. It is just positioned to lose.

Why the change does not take effect immediately

You run usermod, you run docker ps, and you still get permission denied. Nothing is broken.

Supplementary group IDs are a credential attached to a process when it is created. Your shell was created before you joined the group, so it does not carry the membership, and re-reading /etc/group is not something a running process does. The shell will never pick it up. Neither will your desktop session, or the terminal you opened an hour ago.

Docker’s instruction is to log out and log back in so that group membership is re-evaluated, and they note a Linux VM may need a full restart.

To test without logging out:

newgrp docker
docker run hello-world

newgrp starts a subshell that carries the group. It is a session-level patch. Close that shell and you are back where you started, so do not mistake it for the change having applied globally.

The config.json warning nobody explains

If you used sudo docker before joining the group, you will eventually see this:

WARNING: Error loading config file: /home/user/.docker/config.json - stat
/home/user/.docker/config.json: permission denied

Root created that directory in your home. Docker documents the fix:

sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
sudo chmod g+rwx "$HOME/.docker" -R

Cosmetic, not dangerous. It will nag until you clear it.

What to do instead, honestly

I am not going to tell you never to join the docker group. Plenty of people should. The point is to do it knowing what it is.

Rootless mode is the real fix, because it removes the root daemon rather than gating access to one. It has genuine limitations and I have not run it long enough under a homelab workload to tell you which of those bite in practice, so I will not pretend otherwise.

sudo docker keeps every invocation authenticated and logged. It is mildly annoying and it is the correct default on a machine that is not yours alone.

Join the group deliberately on a box where root-equivalent access is already a thing you accept. On a dedicated homelab Docker host that you administer alone and could rebuild in an afternoon, the trade is reasonable and I would make it.

What I would not do is join the group on a shared machine, a work laptop, or anything with credentials on it you would not want a container to read, and then tell myself it was a permissions tweak.

The same reasoning governs anything you point at that socket. A Dockge or Portainer container with the socket mounted is not a dashboard; it is that same root-equivalent access with a web login in front of it.

The Docker Desktop exception

This is the one place the warning genuinely does not carry over. On Docker Desktop the daemon and your containers run inside a Linux VM, and Docker documents that VM as the security boundary. Container root is not host root in the way it is on a native Linux install.

Do not port the Linux Engine threat model onto Desktop unexamined. Do not port Desktop’s comfort back onto a Linux server either — on Windows, docker-users carries its own warning, in Docker’s words equivalent to granting administrative privileges on the host.

What I have not tested

I have not run rootless mode as a daily driver, so I cannot tell you where its limitations actually hurt versus where they are theoretical.

I have not audited whether any mainstream distro ships auditd rules that would record socket writes by group members. My claim above is that sudo logs and group membership does not, which follows from how each works, but I have not sat down and confirmed what a default install captures.

What getting this wrong costs

On your own homelab box, usually nothing. That is exactly why the habit spreads.

The bill arrives somewhere else. It arrives when the same muscle memory runs usermod -aG docker on a shared build server, and the service account that now has passwordless unlogged root is the one whose CI token leaks six months later. Nobody has to attack Docker. The group was the grant.

Run the command if it suits your machine. Just do not believe it only saves you four keystrokes.

Docker Cleanup: Which Prune Command Eats Your Data (2026)

LK Wood IV — Sat, 15 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-15 · ~8 min read · St. Louis County, MO

The received wisdom is simple. docker system prune -a --volumes eats databases, so never run it.

That fear is aimed at the wrong command. Docker’s own options table describes --volumes as “Prune anonymous volumes”, and the confirmation prompt spells out what it will remove: all anonymous volumes not used by at least one container. A named volume is not anonymous. If your Postgres data lives in a volume you named in a compose file, docker system prune -a --volumes is not the thing that will take it.

The command that removes named volumes is this one.

docker volume prune --all

Docker documents that by default docker volume prune only removes anonymous volumes, and that --all removes all unused volumes, not just anonymous ones, behind an API 1.42 gate. Read those two sentences next to each other and the asymmetry is obvious: the destructive option is a four-character flag on a command whose name sounds like it only touches leftovers.

So the scary-sounding command is narrower than its reputation. The mild-sounding one is the loaded gun. That inversion — feared command safe, safe-sounding command dangerous — is the whole reason this page exists.

One honest caveat before you act on any of it. Everything above is read from Docker’s current documentation, not from a test I ran on this machine. I have no Docker daemon here, and I would rather say so than imply a bench I did not use. There is a two-minute scratch test at the end. Run it first. Trust it over me.

Look before you sweep

docker system df

That breaks usage into images, containers, local volumes and build cache, with a reclaimable column. Run it first. Every time.

I push this because “reclaim disk space” is usually the wrong framing, and running a prune before you have looked at docker system df is how people end up re-pulling forty gigabytes of images to solve a problem that was one container writing an unbounded log file the whole time. The question is what filled the disk, and the answer changes the fix entirely. Build cache on a machine that builds often is a different problem from forty pulled images you never run, which is different again from one container writing an unbounded log. Only one of those is solved by pruning.

What each command removes

docker system prune, per its confirmation prompt, removes exactly four things:

all stopped containers
all networks not used by at least one container
all dangling images
unused build cache

No volumes at all. A dangling image — one that no tag points at any more — is typically what is left after rebuilding under the same tag.

docker system prune -a adds, per the options table: Remove all unused images not just dangling ones.

This is a much wider sweep than it reads. “Unused” means no container is associated with the image, tagged or not. On a homelab where you keep images around for things you run occasionally, -a removes them and you will pull them again over your home connection at the least convenient moment. It is safe for your data. It is expensive for your time.

docker system prune --volumes adds anonymous volumes, as covered above.

docker volume prune takes anonymous volumes only, by default.

docker volume prune --all is the one to watch. Unused named volumes go too.

docker builder prune takes build cache only. It is the safest command here, because build cache is reproducible by definition. On a machine that builds regularly it is also often the entire problem.

The trap that is genuinely real

Here is the case where you can genuinely lose data to anonymous-volume pruning. It is not the one people worry about.

Some official images declare a VOLUME in their Dockerfile. Postgres declares one at its data directory. When you start such an image without giving it a named volume or a bind mount, Docker satisfies that declaration by creating an anonymous volume. It has a long hex name you never chose. It holds your actual database.

# creates an anonymous volume holding real data
docker run -d postgres:17

# creates a named volume you control
docker run -d -v pgdata:/var/lib/postgresql/data postgres:17

Stop that first container and the anonymous volume is now unused, and squarely in scope for --volumes.

So the failure mode is not “prune ate my named volume”. It is “I never named the volume, so Docker quietly named it for me, that autogenerated name made it anonymous by definition, and anonymous is precisely the category the flag I ran was documented to remove”. The fix is upstream of any prune command: name your volumes. A compose file with a top-level volumes: block gets this right by default, which is one more reason to run things through compose rather than long docker run lines.

What I run weekly

Weekly, on a homelab Docker host, with the reasoning attached:

docker system df # look first
docker builder prune # cache is reproducible
docker system prune # stopped containers, unused networks, dangling images

That reclaims most of what accumulates. It touches nothing you cannot rebuild.

I add -a only when I have decided I am willing to re-pull, which on a metered or slow connection is a real cost rather than a theoretical one.

I never run docker volume prune --all on a schedule. A volume is the one thing here that might be the only copy. When I want a specific volume gone, I look at it first and then remove it by name, which is slower in exactly the way that a command capable of destroying the only copy of something ought to be:

docker volume ls
docker volume inspect <name>
docker volume rm <name>

Slower. It also makes me say what I mean.

The scratch test, so you do not have to take my word for it

Two minutes, on a machine where losing the test volumes costs nothing.

docker volume create keepme
docker run -d --name anon-test postgres:17 # anonymous volume
docker run -d --name named-test -v keepme:/data alpine sleep 60
docker rm -f anon-test named-test

docker volume ls # note what exists
docker system prune -a --volumes # the feared command
docker volume ls # keepme should still be here

If keepme survives and the hex-named one does not, the documented behaviour holds on your version. If it does not survive, I want to know — that would mean the docs and your daemon disagree, which is a much more interesting problem than a tidy disk.

What I have not tested

I have not run any of this on a live daemon during this write-up, for the reason given at the top. Every behavioural claim here traces to Docker’s current CLI documentation.

I have not checked how an older daemon behaves, and this is the gap I would most want closed before anyone runs these commands on a long-lived box that has not been updated in a couple of years. --all on docker volume prune carries an API 1.42 gate, which implies the pre-1.42 behaviour differed, and I have not established what a new CLI does against an old daemon. If you are on something long-lived and unpatched, test rather than assume.

I have not measured how much any of this reclaims in practice. That number is a property of your machine, and quoting mine would tell you nothing.

What getting it wrong costs

Pruning images costs you a download. Pruning build cache costs one slow build. Both are annoyances with a known price.

Pruning a volume costs you whatever was in it, and the price is only discovered later, usually when something tries to read data that is no longer there and fails in a way that does not obviously say “your volume is gone”. If that data mattered, the real lesson is not about prune flags at all. It is that a volume you would miss should be backed up, because a wrong flag is only one of many ways to lose it.

Docker Compose Environment Variables: .env Is Not env_file (2026)

LK Wood IV — Sat, 15 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-15 · ~9 min read · St. Louis County, MO

Put a .env file next to your compose.yaml, fill it with variables, start the stack, and exec into the container to check.

They are not there.

This is the single most common Compose confusion. It is also not carelessness.

The two mechanisms have similar names, similar syntax, and point in opposite directions.

.env fills ${VAR} placeholders in the compose file itself. By itself it puts nothing in a container.
env_file: passes variables into the container, and is not consulted when Compose interpolates the compose file.

Docker says the first half plainly. Their precedence page notes that the Host OS environment and .env file columns are listed only for illustration purposes, and that in reality they do not result in a variable in the container by itself.

Read that twice. It is the whole article.

The two directions, side by side

# .env (interpolation source)
POSTGRES_VERSION=17

# compose.yaml
services:
 db:
 image: postgres:${POSTGRES_VERSION}  # .env fills THIS
 env_file:
 - db.env  # this goes INTO the container
 environment:
 - TZ=America/Chicago  # so does this

POSTGRES_VERSION never reaches the container.

TZ and everything in db.env do reach it, and neither of them can interpolate anything, which means the file you edited and the file you needed to edit are frequently different files.

The mirror-image mistake is just as common and harder to spot:

services:
 web:
 image: "webapp:${TAG}" # TAG will NOT come from env_file
 env_file:
 - .env

Listing .env under env_file: does not make its contents available for interpolation. It makes them available inside the container, which is a different thing that you did not ask for.

Precedence, in the order Docker documents

Highest to lowest, for what ends up in the container:

docker compose run -e on the CLI
environment or env_file with no value — passes through from your shell
the environment attribute
the env_file attribute
a Dockerfile ARG or ENV

Two entries in that list catch people.

environment beats env_file, even when it is empty. Docker’s wording is explicit that this holds true even if those values are empty or undefined. So a leftover FOO= under environment: silently overrides a correct FOO in your env file. Nothing warns you. The variable is simply empty, and you spend the next twenty minutes reading the env file, which is correct, because the problem is in the other file entirely.

A Dockerfile default is a fallback. The docs state that having any ARG or ENV setting in a Dockerfile evaluates only if there is no Compose entry for environment, env_file or run --env. You do not layer on top of it. You replace it entirely.

There is also a second, different precedence list in the docs covering interpolation: shell, then --env-file, then the project .env. Two lists. Two jobs. Reading one and applying it to the other is how people end up certain the docs contradict themselves.

The silent failures

This is what makes the topic worth a page rather than a paragraph.

Almost every way to get it wrong fails quietly.

Unset interpolated variables become empty strings, not errors.

image: "postgres:${POSTGRES_VERSION}"

With POSTGRES_VERSION unset, that resolves to postgres:, which the docs note is not a valid image reference.

Compose builds the string anyway and hands you the failure one layer down, where the error message talks about an image rather than about the variable that produced it, so the search you run next is the wrong search.

Bare passthrough does not warn; the explicit form does.

environment:
 - DEBUG  # unset? no warning, nothing passed
 - DEBUG=${DEBUG}  # unset? Compose warns

Both are legal. Only the second tells you when the shell had nothing to give. I use it for that reason alone.

A missing --env-file is a hard error. A missing .env is silent.

That asymmetry is deliberate. A path you named explicitly is a promise; the default is optional. It also means a stack that runs on your laptop can start on the server with a chunk of its configuration quietly absent, because .env was never committed and nobody noticed it was gone.

I check for that first now, whenever something runs locally and not on the host. It is nearly always this.

Secrets do not belong here

Anything you put in the container environment is readable with docker inspect. That means it is readable by anyone who can reach the Docker socket — and on a Linux host, that is anyone in the docker group, which is root-equivalent access anyway.

Compose supports file-based secrets that arrive at /run/secrets/<name> instead:

services:
 db:
 image: postgres:17
 environment:
 POSTGRES_PASSWORD_FILE: /run/secrets/db_password
 secrets:
 - db_password

secrets:
 db_password:
 file: ./db_password.txt

Note the pattern in that block. The environment variable holds a path. The secret itself never enters the environment. Many official images support a _FILE suffix on their password variables for exactly this, and where an image supports it, it is strictly better than pasting the value.

ARG deserves a specific warning too: build arguments are visible in the image history. An ARG carrying a token is published rather than private, and it stays published in every layer built from it.

What I do

A .env for things that shape the compose file: versions, ports, host paths.

An env_file per service for what the application reads.

environment for one or two values I want visible in the compose file itself, so that reading the file tells the truth about what the service gets rather than sending the reader off to a second file to find out.

The rule I hold to, after being bitten by the empty-override: never set the same variable in two places. Precedence rules exist so that Compose can resolve a conflict, not so that I can create one and rely on remembering the order at 1am.

What I have not tested

I have not verified the behaviour on old Compose v1. Everything here is from current Compose documentation, and v1 differed in enough places that I would not extend it there.

I have not tested how the newer top-level include: interacts with .env resolution across multiple compose files, which is the case I would most expect to hold a surprise.

What getting it wrong costs

Usually an hour. The hour has a distinctive shape: the configuration looks correct, the container disagrees, and nothing produces an error that points at either one.

Occasionally it costs more. environment silently overriding an env-file value with an empty string is a fine way to start a database with an empty password variable, and the failure mode there depends entirely on how forgiving the image is about it. Some are not forgiving at all, which is the good outcome.

Dockge Setup: The Compose Manager That Does Less On Purpose (2026)

LK Wood IV — Sat, 15 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-15 · ~7 min read · St. Louis County, MO

Dockge is a web UI over a folder of docker-compose.yaml files. That sentence is the entire product. I mean it as praise.

The install is one container. Five minutes, most of it waiting on a pull. The thing worth reading this page for is the volume line in the middle of that file, because getting it wrong is the one failure the project cared enough about to put a warning emoji beside in its own README, and because it fails quietly rather than loudly.

The compose file

services:
 dockge:
 image: louislam/dockge:1
 restart: unless-stopped
 ports:
 - 5001:5001
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 - ./data:/app/data
 # Both sides of this MUST be the same path. See below.
 - /opt/stacks:/opt/stacks
 environment:
 - DOCKGE_STACKS_DIR=/opt/stacks
 - PUID=1000
 - PGID=1000

mkdir -p /opt/dockge /opt/stacks && cd /opt/dockge
# save the file above as compose.yaml
docker compose up -d

Then open port 5001 and create the admin account. Done.

Before you run that: the stable image is old

I nearly published this page without checking. That would have been a disservice, so here it is up front, ahead of the install advice rather than buried in a caveats section at the bottom where nobody reads it.

Dockge 1.5.0 was released on 30 March 2025. On Docker Hub the tags 1, latest and 1.5.0 all resolve to one digest, and all three were last pushed that same day. The 1 tag in the compose file above is therefore an image that has not been rebuilt in roughly sixteen months.

The project is not abandoned. Master took commits into April 2026, and there is a nightly tag rebuilt daily from it, which I confirmed had been pushed the day I wrote this. What has stalled is the release. The gap between the code and the artefact you actually pull is the part that matters, and it is the part a version number on a README will never show you.

Now weigh that against the socket mount in the next section. This is a container holding root-equivalent access to your host, running an image whose base layers have not been refreshed in over a year. Those two facts are worse together than either is alone.

I still think it is worth running. On a LAN-only host, behind a proxy, on a homelab you could rebuild in an afternoon. I would not put it on anything internet-facing, and I would not put it on a machine whose loss would ruin a week. You can pin nightly for the newer code. Then you are on unreviewed daily builds, which is a different risk, not a smaller one.

Check the dates yourself before installing. They may well have moved since I wrote this:

curl -s "https://hub.docker.com/v2/repositories/louislam/dockge/tags?page_size=10&ordering=last_updated" | python -c "import json,sys; [print(t['name'], t['last_updated'][:10]) for t in json.load(sys.stdin)['results']]"

The volume line

Look at the stacks mount again:

- /opt/stacks:/opt/stacks

Host path on the left, container path on the right. They are identical, and that is not stylistic. The README’s own examples are blunt about it — it marks /my-stacks:/my-stacks correct because both paths match, and /docker:/my-stacks wrong because they do not, with the warning that your data could end up written into a wrong path.

Here is why. “Just do it” is unsatisfying, and you will meet this shape again.

Dockge talks to the Docker daemon through the socket you mounted. When it asks the daemon to bring up a stack, the daemon resolves every path in that compose file on the host, not inside the Dockge container. So Dockge writes a compose file to what it believes is /opt/stacks/immich/compose.yaml, and the daemon goes looking for that same path on the host. If your bind was /docker:/opt/stacks, then Dockge’s /opt/stacks/immich is really /docker/immich on the host, and the two halves of the system now disagree about where your stacks live.

Make both sides identical and the disagreement cannot happen. It is the same class of problem as any socket-mounted tool that hands paths to the daemon, and the fix is always the same: agree with the host.

/opt/stacks is only a convention, and /srv/stacks:/srv/stacks would do just as well, because what the daemon cares about is that the two sides agree rather than what they agree on. Matching is the rule. The path is yours.

What it deliberately will not do

Dockge is compose-only. It will not manage standalone containers, networks, images, or the rest of the Docker surface Portainer covers.

I think that is the most interesting thing about it. It is also the part people get annoyed by, because they arrive expecting a Portainer swap and find something with a deliberately smaller footprint instead. If every workload you run is a compose stack — which, in a homelab, it usually is — then a tool that only does stacks has a much smaller surface to be confusing in. If you regularly poke at networks or one-off containers, Dockge will not cover that and you will keep a terminal open. Neither of those is a defect. They are just different jobs.

I compare it properly against the two obvious alternatives in Komodo vs Portainer vs Dockge, including the licensing change that pushed a lot of people to look in the first place.

Security, briefly, because the socket mount deserves it

That first volume line mounts the Docker socket into the container. Anything that can reach the Docker socket can start a container that mounts your host filesystem as root. That is not a partial privilege. It is root.

So the Dockge UI is not a dashboard. It is a root-equivalent control surface with a login form in front of it. Treat it that way:

Do not publish 5001 to the internet. Put it behind Nginx Proxy Manager with a real certificate, or reach it over a tunnel and leave it on the LAN entirely.
Give it a password you did not reuse.

If you already run Uptime Kuma, the same reasoning applies there and the same fix works for both.

PUID and PGID

The official file sets both to 1000, and its comment is worth repeating: both must be set for it to do anything. Setting one alone does nothing at all.

They decide who owns the stack files Dockge writes. Get them wrong and the symptom is undramatic — you SSH in later, try to edit a compose file by hand, and cannot, because it belongs to someone else. id -u and id -g give you the right numbers for your own user.

Adopting stacks you already have

Dockge reads a directory. There is no import step, and no separate database holding the real state, so a compose file you drop into the stacks directory is simply a stack it can see.

That property is the reason I find it easy to recommend trying. The compose files are the state. Nothing else is. If you decide against it in a month, you stop the container and your stacks are exactly where you left them, in plain files, unchanged. Tools that own their state are a commitment; this one is a visit.

What I have not tested

I have not run the agent/multi-host setup, so I cannot tell you how it behaves when a remote host goes away mid-deploy, which is the case I would want to know about before depending on it.

I have not measured its resource use, and I would rather say that than quote a figure I did not take.

I have also not run it against a stack large enough to make the UI struggle, so I do not know where that boundary sits.

What getting the volume wrong costs

Not much, if you catch it on day one. You notice the stacks are not where you expected, you fix the bind, you move on.

The expensive version is catching it in month four, after you have pointed a backup job at /opt/stacks on the host and it has been faithfully archiving an empty directory the whole time. The compose files were always at /docker. Nothing errored, because nothing was wrong from any single component’s point of view.

Check the two paths match. Before anything else.