TechFuel HQ

Name: TechFuelHQ PSU Tier List 2026
Creator: TechFuelHQ
License: https://creativecommons.org/licenses/by/4.0/

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.

Headscale: Self-Hosting the Tailscale Control Server (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

Most people who look up Headscale want to run it on the machine already humming in their closet. That is the one deployment it does not do.

Headscale’s own requirements page asks for a server with a public IP address, recommends dual-stack IPv4 and IPv6, and serves over HTTPS on port 443 because the Tailscale client assumes that in certain situations. If your home connection sits behind CGNAT, you have no public IP to hand it. If it does have a real public IP, you can technically proceed, and you will have built a coordination server that depends on the same uplink as everything it coordinates.

So the shape of a Headscale deployment is fixed before you write any config: a small host somewhere else, with a public address and a name you can put a certificate on.

That is the practical answer. The more useful answer is the next section.

First, the case against doing this

Tailscale’s free Personal plan covers up to 6 users with unlimited user devices, 3 ACL groups, and access to nearly all features. It costs nothing and it is explicitly intended for homelabs and personal projects.

Read that against your actual situation. One person, a NAS, a Proxmox host, three VMs, a laptop and a phone? You are not close to a limit. There is no bill coming. Headscale would replace a working, maintained, zero-cost service with one you patch, back up, and get paged about.

I want to be blunt, because the search results for this topic are not: for the majority of homelabs, Headscale solves a problem you do not have. Running it is a hobby in its own right, and that is a completely legitimate reason to run it. It is not the same reason as necessity, and the two get blurred constantly.

Three situations where it genuinely earns the work:

You object to the metadata, not the cost. Tailscale’s coordination server knows your device names, your public keys, and who connects to what. The traffic is end-to-end encrypted and they cannot read it, but the graph is theirs. If that specific fact is what bothers you, Headscale is a direct answer and no amount of free tier fixes it.

Your structure does not fit the Personal plan. More than 6 users, or an ACL model that needs more than 3 groups, and you are looking at a paid tier. At that point the comparison is a real one.

You want the control plane to survive theirs. Existing tailnets keep passing traffic when the coordination server is unreachable, but new nodes and key rotations do not. If your tolerance for that is zero, owning the control plane is the only fix.

Everything else — “self-hosting is better,” “I want to own my stack” — is preference, and preference is fine. Just price it honestly against a free service that already works.

What it does support

The 2026 feature list is broad, which surprised me. Node registration by web auth and pre-auth keys, MagicDNS, split DNS and search domains, tags, subnet routers, exit nodes with route filtering, dual-stack, ephemeral nodes, embedded DERP and peer relays, ACLs and grants, autogroups, Tailscale SSH, OIDC single sign-on, Taildrop and Taildrive, Funnel and Serve, network flow logs.

The documented gap worth checking before you commit: OIDC groups cannot be used in ACLs. If your plan was to point Headscale at your identity provider and let group membership drive access policy, that specific path is closed. Verify it against your intended policy now rather than after you have migrated forty nodes.

Headscale is not a Tailscale product. It reimplements a protocol it does not control, which is the standing structural risk with anything in this category and is worth naming even though the project has tracked upstream well.

The host

A control server does very little work. It coordinates key exchange and hands out routes, then gets out of the way while nodes talk directly. SQLite is the assumed database in the setup requirements, so there is no separate database tier to size.

What it needs is not capacity. It is position:

A public IPv4 address. Dual-stack with IPv6 is recommended.
Port 443 reachable, with a valid certificate.
Uptime that is independent of the network it serves.

Any small VPS tier meets the first two. The third is the one people undercut by hosting it at home, and it is the whole reason the requirement exists.

There is one more reason not to put it on your home connection, and it is the sharpest: if Headscale is the thing that lets you reach your homelab remotely, and Headscale lives in your homelab, then you cannot fix your homelab remotely. You have built a mesh VPN whose failure mode is a locked door with the key inside. I would put the control server anywhere except the network it exists to let me into.

The domain

HTTPS on 443 means a certificate, and a certificate means a hostname. A subdomain on a domain you already own works fine — nothing about this needs a dedicated registration.

If you do not own one yet, this is the same purchase you would make for any public service, and it is worth doing before the install rather than during it. Certificate issuance is the step where a missing DNS record turns twenty minutes into an evening.

Where this sits against the alternatives

If you have not committed yet, the comparison is worth doing properly. I have written up Tailscale against plain WireGuard, which is the real decision for most people, and Tailscale against Cloudflare Tunnel for the case where you want to publish rather than connect. NetBird against Tailscale covers the other self-hostable mesh worth a look, and it is the one I would compare Headscale to most carefully, because it was designed to be self-hosted rather than adapted to it.

If you just want remote access to your homelab today and are not attached to owning the control plane, Tailscale on a homelab takes about ten minutes. If you want no third party in the path at all, WireGuard on Proxmox is the honest floor — more manual, no coordination server to run, no vendor.

What I have not tested

I have not run Headscale through a Tailscale client major-version bump, which is the failure mode I would most want data on before recommending it to someone whose remote access depends on it. The project tracks upstream well by reputation. Reputation is not a measurement.

I have not tested the OIDC integration, so I cannot tell you how painful the ACL group limitation is in practice, only that it is documented.

I have not run it at a scale where SQLite is the constraint.

What getting this wrong costs

The expensive version is not a failed install. It is a successful one, six months ago, on a box in the closet, which you have quietly come to depend on. Then the power blips while you are travelling, and the control server that would have let you back in is the thing that is down.

Put it somewhere else. That is most of the advice on this page.

Monitor Shadow Problem: Three Different Faults Wearing One Name (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

Ten feet.

That is the run length where ViewSonic stops assuming your HDMI cable is fine — and it is the most useful number in this entire topic, because almost nobody staring at a shadowed screen has stopped to think about how long their cable actually is, how many boxes it passes through on the way, or whether the connector behind the monitor has been quietly oxidising in a warm room since 2019. They are thinking about whether the monitor is dying. It usually is not.

TL;DR · Find out which shadow you have

Drag a window across the screen and watch the shadow. Everything below depends on this one observation.
Holds a fixed offset and follows the window → signal path. Pull the dock, reseat the cable, get off VGA. Cheapest fix on the page.
Only appears while things move, gone when still → pixel response time. Different fault, different guide.
Faint copy of a taskbar or spreadsheet left up for hours → image persistence. Leave it alone and it goes.
Cuts through the monitor's own settings menu → the panel itself, and that menu is the referee.

Most guides on this topic make one mistake, and it is why people replace working monitors. They treat “shadow”, “ghosting” and “double image” as one problem with one list of fixes. Search the phrase and you get a single article covering cables and response time and burn-in in the same breath, as though the reader should simply work down the list until something helps. Those are three faults with nothing in common except the word people reach for when describing them.

The list approach costs you an evening and, often enough, a monitor.

The test that decides everything

Open any window and drag it slowly across the screen.

If the duplicate travels with the window and keeps the same offset, the image is being corrupted on its way to the panel. If the duplicate only exists during the drag and the screen is clean the moment you let go, the pixels are switching too slowly. If there is no duplicate at all, and what you are seeing is a faint ghost of yesterday’s spreadsheet sitting in one place regardless of what gets dragged over the top of it, then nothing is broken and you can stop worrying.

Three answers. Skip to yours.

The shadow that holds still: your signal path

This is the one worth real attention, because it accounts for most of the searches and it is almost always the cheapest thing in the chain.

A monitor draws what arrives at its input. It cannot do anything else. When the picture arrives degraded, the panel faithfully draws the degradation, and one of the recognisable ways a video signal degrades is as a displaced, lower-contrast copy of the real image. ViewSonic’s own support article on shadowing and double images is blunt about the mechanism: image artifacts are typically caused by signal degradation or interference. That is a panel manufacturer describing its own returns.

VGA sits at the top of the list

Let me be careful about how hard I lean on this.

I have never put a scope on a VGA line myself, and I am not going to pretend otherwise. What I can tell you is what the manufacturer says, and ViewSonic states plainly that low-quality VGA cables are the most common cause of shadowing, with the recommendation to use HDMI or DisplayPort instead.

The reasoning holds up. VGA carries the picture as an analogue waveform, so degradation along the way lands directly in what you see — no error correction, no fallback, just a slightly wrong voltage arriving at a panel that has no way of knowing it is wrong. A digital link fails differently. It either delivers a pixel correctly or breaks in ways that look nothing like a soft double image: sparkles, black flashes, a dropped signal, a refresh rate that silently falls back to 30Hz. If you are on VGA and both ends have a spare HDMI or DisplayPort, that swap is a five-minute test which costs nothing and settles the question outright. The catch is that plenty of people are running VGA without knowing it, because a VGA-to-HDMI adapter on a monitor’s input, or an old KVM with an analogue backbone, keeps the analogue segment sitting in the middle of the chain while the connector at your desk looks perfectly modern and the box on your shelf says nothing about what it does internally.

Check the back of the monitor before you rule this out.

Every box between the two ends is a suspect

ViewSonic’s first recommended step is to remove any docking stations or video splitters and connect the monitor directly to the PC to test the image quality. That ordering is right, and it is the step people skip, because unplugging a dock means unplugging everything.

Do it anyway. A dock, a splitter, a KVM and a USB-C hub are all re-driving or re-timing your video, and a cheap one does that badly. If the shadow disappears with the monitor plugged straight into the graphics card, you have found it. You also know what the fix costs, which is the part people want before they start. If you arrived here because a second display was misbehaving too, our guide on a second monitor that will not be detected covers the same hardware from the other direction.

Length, and the one certification that means something

Past about ten feet, cable quality stops being a rounding error. ViewSonic’s threshold is three metres, and the recommendation is a Premium Certified HDMI cable or a high-quality shielded one.

That certification is not marketing. Under the Premium HDMI Cable Certification Program, cables are tested to support the full 18Gbps bandwidth, including an EMI test to make sure they minimise interference with wireless signals, and — this is the part that matters for a long desk run — the program requires every length of every model line to be tested at an official HDMI Authorized Test Center, so a 25-foot cable cannot ride in on the results of its 3-foot sibling. Certified cables carry an anti-counterfeiting label with a QR code you can scan in the shop. That is a meaningfully different claim from “high speed” printed on a bag.

DisplayPort has an equivalent worth knowing. VESA’s DP8K certification confirms a cable handles HBR3 — the 8.1 Gbps-per-lane rate DisplayPort 1.4 tops out at — verified at an authorised test centre rather than asserted on the packaging. It also checks that pin 20 is not wired through on male-to-male cables. That one is a nastier failure than any shadow, since back-driven power can stop a machine booting.

Then the boring physical things

Reseat both ends. ViewSonic asks you to make sure the connectors are clean, with no oxidation, and are seated properly in the port, which sounds like filler right up until you remember what actually happens to a monitor cable behind a desk: it gets yanked when the desk moves, kinked against a wall, stood on by a chair caster, and left in a warm room for six or seven years while nobody once looks at the pins. Then someone buys a new monitor.

If none of that moves the needle, bring up the monitor’s own on-screen menu while the shadow is visible. That menu is drawn by the monitor’s internal board and never touches your cable, so a shadow cutting through the menu overlay puts the fault inside the display. I did not invent that test. It is the same referee our guide to lines on a monitor screen uses, and it works here for the same reason.

The shadow that only exists in motion

If the duplicate appears behind moving objects and the screen is clean when nothing moves, stop reading this page. You have ghosting, and this page will not help you. That is a pixel response-time problem inside the panel, and the fix is your monitor’s overdrive setting rather than anything in the cable chain. We wrote it up separately in how to fix monitor ghosting.

One thing is worth flagging, because it is the most common wasted purchase in this whole area. A new cable will do nothing for ghosting. Not one thing. The advice on the two faults points in opposite directions, which is exactly why bundling them into one article does readers harm.

The shadow that fades on its own

The third case is a faint copy of something that sat on screen for a long time. A taskbar. A spreadsheet grid. A dashboard someone left up over a weekend.

That is image persistence, and on an LCD it is temporary. Dell’s monitor guidance treats it as a condition that clears once the static content stops being shown, and recommends screen savers and varied content as the prevention. Leave the display on ordinary moving content, or switch it off, and it goes. How long that takes ranges from seconds to considerably longer depending on how long the static image sat there, so patience is genuinely part of the fix here.

Do not buy anything for this one.

OLED is the exception, and the distinction matters if you are running a TV as a desktop. There, prolonged static content can produce permanent wear rather than temporary retention. That is a different conversation. There is no home fix.

The case where the monitor is innocent

One search that lands people here has nothing to do with display hardware at all. Windows draws drop shadows under window borders, and a display-scaling change or a graphics-driver reset can render those shadows heavier, or leave them stranded behind inactive windows. If your “shadow” is a soft grey edge hugging window frames, no cable will touch it.

So take a screenshot. That settles it in about four seconds, because a real signal or panel fault never survives being captured to a file, while a compositor artifact is baked into the image and will look exactly the same on any other machine you open the file on.

What I have not tested

I have not reproduced any of these faults on a bench for this article, and the sourcing above reflects that: the signal-path claims are ViewSonic’s, the cable-certification specifics are HDMI Licensing’s and VESA’s, and the image-persistence behaviour is Dell’s. Where those sources agree with the physics I have said so, and where I am simply relaying a manufacturer’s claim I have tried to make that obvious.

I also cannot tell you how much of the shadowing people report in 2026 is still VGA. ViewSonic’s guidance does not carry a date I can check, and analogue connections have been disappearing from new hardware for a decade while surviving in offices, classrooms and KVM setups. The advice holds either way, since the diagnostic sequence does not depend on which cause turns out to be most common.

The next thing I would measure, if I put a monitor on the bench for this, is whether a failing HDMI run degrades gradually into visible shadowing or falls off a cliff into sparkle and signal loss with nothing in between. My expectation is the cliff, which would make a soft shadow on a short digital cable a much stronger indicator of a dock or adapter problem than of the cable itself.

Sources

ViewSonic Support, “Why is there shadow or double image on screen?” — signal degradation as cause, VGA as most common source, dock/splitter removal, three-metre cable threshold, connector oxidation.
HDMI Licensing Administrator, Premium HDMI Cable Certification Program — 18Gbps testing, EMI test, per-length testing at Authorized Test Centers, QR-code authentication label.
VESA, DP8K certified DisplayPort cables — HBR3 at 8.1 Gbps per lane, authorised test centre verification, pin 20 checking.
Dell, Guidelines for Dell Monitor Usage to Prevent Image Retention and Preserve Panel Life — image retention as a temporary LCD condition, prevention guidance.

Ollama in Docker with GPU: Stop Installing CUDA Inside WSL2 (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

If you are on WSL2, the most common first move is the wrong one, and it feels like progress while you make it.

People open the distro, run apt install cuda or cuda-drivers, check nvcc --version, see a version string, and treat the prerequisite as handled.

NVIDIA’s own CUDA-on-WSL documentation warns against exactly this. More than once. One of those warnings is in capitals.

Here is why it is not merely unnecessary but harmful. Under WSL2 the Windows driver is projected into the distro as a libcuda.so stub. That stub is the GPU access path. The cuda, cuda-12-x and cuda-drivers meta-packages pull in a Linux NVIDIA driver, which installs over that stub and breaks the thing that was working.

You do not need a driver inside WSL. You already have one. It came from Windows.

The two toolkits people conflate

This is the root of it. The naming is genuinely unhelpful:

Package	What it does	Needed for Ollama in Docker?
CUDA Toolkit (`nvcc`, headers)	compiles CUDA applications	No
NVIDIA Container Toolkit (`nvidia-container-toolkit`)	lets Docker hand a GPU to a container	Yes

They share a brand. Nothing else. nvcc --version printing happily tells you precisely nothing about whether Docker can reach your GPU — I have watched that exact screenshot get posted as evidence in bug reports where the real failure was that the container toolkit was never installed.

You want the second one.

On Debian or Ubuntu:

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
 | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -fsSL https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
 | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
 | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit

This is the same package on native Linux and inside WSL2. The only difference is where you stop: on WSL2 that command is the end of it, whereas on native Linux you also need a real NVIDIA driver underneath, which is the step WSL2 users are trying to replicate when they break their stub.

Running it

docker run -d --gpus=all \
 -v ollama:/root/.ollama \
 -p 11434:11434 \
 --name ollama ollama/ollama

docker exec -it ollama ollama run llama3.2

Drop --gpus=all and you get a working CPU install. That is a reasonable first move: it confirms the rest of your setup before you start fighting the GPU layer, and it means a later failure has exactly one new variable in it.

For AMD, the image and the flags both change:

docker run -d --device /dev/kfd --device /dev/dri \
 -v ollama:/root/.ollama -p 11434:11434 \
 --name ollama ollama/ollama:rocm

Note the volume is named.

/root/.ollama holds your downloaded models, and those are large. An anonymous volume there is how people re-download forty gigabytes after a cleanup — see which prune command eats data for why that happens.

Where 11434 really listens

There is bad advice in circulation. It says Ollama binds 127.0.0.1 by default, so publishing the port is safe.

That is true of a native install. It is not true of this image. The official container sets OLLAMA_HOST=0.0.0.0:11434 in its Dockerfile, so inside the container it listens on everything, and whatever you publish with -p is genuinely reachable.

Ollama’s API has no authentication. -p 11434:11434 on a machine with a public IP publishes an unauthenticated inference endpoint on someone else’s hardware budget. Bind it to localhost explicitly if you want it host-only:

-p 127.0.0.1:11434:11434

Compose, where –gpus does not exist

This is the second thing that costs people an evening.

--gpus=all is a docker run flag. Compose does not accept it as a service key, and the error you get does not point anywhere useful.

services:
 ollama:
 image: ollama/ollama
 volumes:
 - ollama:/root/.ollama
 ports:
 - "127.0.0.1:11434:11434"
 deploy:
 resources:
 reservations:
 devices:
 - driver: nvidia
 count: all
 capabilities: [gpu]

volumes:
 ollama:

Two rules inside that block, both documented and both easy to trip:

capabilities is not optional. Docker’s docs state that omitting it errors on service deployment. It looks like decoration and it is required.
count and device_ids are mutually exclusive. Pick one, or it errors.

There is also a newer top-level gpus: attribute if your Compose version has it, which is less verbose for the common case.

The WSL2 restriction nobody mentions

On WSL2, NVIDIA documents that only --gpus all is supported.

You cannot filter by index or UUID.

So a compose file pinning device_ids: ['0'] is documented as not workable under WSL2, even though the identical file is fine on native Linux. If you have two GPUs in a Windows box and were planning to give one to Ollama and keep the other for something else, that plan does not survive contact with WSL2.

That single limitation is the strongest argument I know for putting the LLM host on native Linux rather than WSL2, assuming you have the choice, and it is the kind of constraint that only shows up after you have already built the thing around the assumption that a GPU is a GPU.

Adding Open WebUI

The obvious next step is a browser interface. Open WebUI’s official stack runs it alongside Ollama, and their :cuda image tag is documented as Nvidia GPU support, to be paired with --gpus all.

One deliberate default worth understanding before you “fix” it: in Open WebUI’s official compose stack, the ollama service publishes no host port at all. 11434 is reachable on the Compose network and nowhere else. That is not an oversight. It means the only thing exposed is the UI, which has accounts, rather than the raw API, which does not.

If you genuinely need the API from the host, they ship a separate api overlay for that. Use it rather than editing the base file, so the reason stays visible.

Verifying the GPU is doing the work

The failure mode here is quiet. Everything runs. It just runs slowly, on the CPU, while you assume otherwise.

docker exec -it ollama nvidia-smi

If that errors, the container cannot see the GPU and no amount of Ollama configuration will help — the problem is the container toolkit or the driver.

Then run a prompt and watch nvidia-smi on the host. If VRAM use does not move and your CPU fans do, the model is not on the GPU. The usual cause is that the model does not fit in VRAM, which is a hardware question rather than a Docker one, and which I have written up separately in local LLMs by GPU VRAM.

What I have not tested

I have not run the ROCm image. The command above comes from Ollama’s documentation and I have no AMD card here to confirm it against, so treat that line as documented rather than verified by me.

I have not tested the newer top-level gpus: Compose attribute, and Compose version support for it is exactly the sort of thing that varies by distro package.

I have not benchmarked WSL2 against native Linux for inference throughput. I believe native is better and I have not measured it, so I am not going to give you a number.

What getting it wrong costs

The CUDA-inside-WSL mistake costs you a working GPU and then several hours, because the symptom appears after the install that felt like progress. You were closer before you started than after.

The -p 11434:11434 mistake costs more, and it costs it quietly. An unauthenticated inference API on a public address does not announce itself. It just becomes somebody else’s free GPU until you notice the electricity bill or the fan noise.

SSH Port Forwarding: -L, -R, -D and Why Your Reverse Tunnel Only Works Locally (2026)

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

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

Three flags. The third is where the afternoon goes.

ssh -L 8080:internal-host:80 user@server # reach IN
ssh -R 8080:localhost:80 user@server # expose OUT
ssh -D 1080 user@server # SOCKS proxy

-L opens a listener on your machine. -R opens one on the server. That is the entire difference. Inverting it is the beginner mistake, and it announces itself immediately, which makes it the cheap one.

The expert mistake is different, and it is the reason this page exists: -R does not fail when it does not work. It succeeds into a state that is not the one you asked for.

The -R trap

You run this on a home machine, against a VPS with a public IP:

ssh -R 8080:localhost:80 user@vps

You expect http://vps-public-ip:8080 to reach the web server at home. From the VPS itself, curl localhost:8080 works perfectly, which is the detail that sends people off debugging their home firewall, their router, and eventually their ISP, when none of those were ever in the path. From anywhere else: connection refused.

Nothing errored. The tunnel is up. It is bound to 127.0.0.1 on the VPS, which is a perfectly good place for a listener to be if that is what you asked for, and you did not.

That is sshd’s documented default. Remote forwards bind loopback unless GatewayPorts is enabled, and it defaults to no.

Then comes the second half, which is the part that costs the extra hour. You reasonably try to force it from the client:

ssh -R 0.0.0.0:8080:localhost:80 user@vps # still loopback-only

It does not help.

ssh(1) is explicit: specifying a remote bind_address will only succeed if the server’s GatewayPorts option is enabled. Your bind address is a request, not an instruction — the server is free to override it, and by default it does exactly that, binding loopback anyway rather than refusing the forward and saying why. A refusal would have cost you thirty seconds. The override costs you the evening.

This is documented in OpenSSH’s own tracker as bug 1297, filed by someone who noticed the socket was always bound to 127.0.0.1 and [::1] and that -L had no such problem. That is the shape of the confusion: local forwards obey you, remote forwards negotiate with a server whose defaults you did not read.

Fixing it, on the correct side

On the server, in sshd_config:

GatewayPorts clientspecified

Then reload sshd. Not your session. The daemon.

I recommend clientspecified over yes deliberately. yes forces remote forwards to bind the wildcard address for every client on that server — a blunt, global change that removes the option of a loopback-only forward from everyone. clientspecified gives each client the choice, so -R 0.0.0.0:8080:... binds wide and a plain -R 8080:... stays local.

The two GatewayPorts

Here is the detail that turns a five-minute fix into a long one, and it is purely a naming accident.

There are two GatewayPorts options with near-identical wording:

File	Governs
`sshd_config` (server)	`-R` listeners the server opens on your behalf
`ssh_config` (client)	your own `-L` and `-D` listeners

They live in different files, on different machines, and do different jobs. Editing the client one, reloading nothing, and then wondering for forty minutes why the reverse tunnel is still loopback-only is an experience I would rather you skip.

Debugging -R? Server file. Every time.

-L, properly

ssh -L [bind_address:]port:host:hostport destination

host:hostport is resolved from the server’s perspective, and that is the entire point of the flag: you are borrowing the server’s view of the network for the duration of the session, which is why it reaches things your own machine has no route to. This reaches a NAS at 192.168.1.50 that your laptop cannot route to:

ssh -L 8080:192.168.1.50:80 user@homelab-gateway

Then browse localhost:8080. That is it.

By default that listener binds loopback on your machine, so nobody else on the coffee-shop wifi can use your tunnel. That default is correct. Leave it.

-L also accepts Unix sockets on either end, which is how you reach a socket-only service like a database or a Docker daemon without publishing a TCP port for it.

-D, the one people underuse

ssh -D 1080 user@server

That is a local SOCKS 4/5 listener. Point a browser’s SOCKS proxy at localhost:1080 and its traffic emerges from the server, with DNS resolved there too if the client is configured for remote DNS.

I reach for this more than -L when I am poking at a homelab, because it needs no per-service forwards. One flag, and the whole network is reachable by its internal names for as long as the session lives.

It is not a VPN. It carries only what an application deliberately sends through the proxy, so anything not SOCKS-aware ignores it completely and silently, which is a distinction people discover at the worst possible moment. If you want everything routed, you want WireGuard or Tailscale, not this.

-J, which is not a tunnel at all

ssh -J bastion.example.com user@internal-host

ProxyJump reaches a final destination through an intermediate. Nothing is published, no listener opens, and the bastion does not see your session in cleartext — your client negotiates end-to-end with the real target.

Keep the distinction clean.

Administrative access to a machine behind a bastion is a -J job.
Exposing a service is a -L or -R job.

I have watched people build an elaborate -L chain for something -J does in one flag, in ~/.ssh/config, permanently:

Host internal-*
ProxyJump bastion.example.com

“administratively prohibited”

channel 3: open failed: administratively prohibited

Two things about this message. The first one saves you a search.

First: the 3 is meaningless. It is OpenSSH’s local channel id from a format string. Searching the literal message with the number in it is why people find nothing.

Second: it means the server refused. Almost nothing more. There are at least three distinct causes, all server-side:

AllowTcpForwarding in sshd_config disallowing that direction. It takes local and remote as values, not just yes and no, so a server can permit -L and refuse -R.
A key option in authorized_keys — no-port-forwarding, or restrict, which turns everything off and then re-enables only what you name after it.
permitopen / PermitOpen restricting forwards to a specific host and port list that does not include the one you asked for.

Check them in that order. The authorized_keys case catches people out most often, because the server’s global config reads permissive and the restriction is sitting on the key itself, which is not where anyone looks second.

Privileged ports behave differently by direction

ssh(1) gives two different rules, and they are easy to conflate:

For -L: only the superuser can forward privileged ports. That is on your side.
For -R: privileged ports can be forwarded only when logging in as root on the remote machine. That is on the server’s side.

So -R 80:localhost:8080 to a VPS fails unless you are logging in as root there, which you should not be. Bind something above 1024 and put a reverse proxy in front of it.

Keeping a tunnel alive

An SSH tunnel is a process. Processes die. For anything you depend on, put it under supervision rather than in a terminal you will eventually close:

# /etc/systemd/system/tunnel.service
[Service]
ExecStart=/usr/bin/ssh -N -T -o ServerAliveInterval=30 -o ExitOnForwardFailure=yes \
 -R 8080:localhost:80 user@vps
Restart=always
RestartSec=10

-N runs no remote command, -T allocates no TTY. ExitOnForwardFailure=yes earns its place: without it, ssh happily stays connected when a forward could not be established, and systemd sees a healthy process fronting a tunnel that carries nothing.

ServerAliveInterval matters because an idle tunnel crossing a NAT gateway is exactly the kind of connection a middlebox reaps without telling either end, leaving you with a socket that looks established on both sides and moves nothing.

Where this stops being the right tool

Reverse tunnels are the classic answer to “my home connection has no public IP”, and for one or two services they remain a genuinely good one, because the alternative is standing up infrastructure to solve a problem that a single flag already solves. They work. I still keep one for a couple of things.

But if you find yourself maintaining several, plus a systemd unit for each, plus GatewayPorts on a server whose config you now have to remember, you have hand-built a worse mesh VPN. That is the point to look at Tailscale or WireGuard, or at running the control plane yourself.

The honest dividing line I use is this. One or two forwards, occasional, and -R is fine.

More than that, or anything a household depends on, and the tunnel collection has quietly become technical debt with a systemd unit attached to each piece.

What I have not tested

I have not verified whether a current client surfaces the loopback downgrade under -v. OpenSSH added a debug message for this case in the 6.4 era, and I could not establish from the sources I read whether that reliably reaches a modern user’s terminal. Assume it is silent and check the listener yourself with ss -tlnp on the server.

I have not tested any of the authorized_keys restriction interactions on a live sshd during this write-up, so treat the ordering advice as a plan of attack rather than a measured result.

What getting it wrong costs

The -R trap costs an evening. That is the good outcome: you conclude nothing works, and go read the docs.

The bad outcome is GatewayPorts yes set globally on a server, forgotten, on a box that also hosts something else. Now every remote forward any account opens binds the wildcard address by default. Somebody tunnels an admin panel out to test something, leaves it up, and there is a listener on a public IP that nobody remembers creating.

clientspecified costs nothing extra and does not accumulate that debt.

Uptime Kuma Docker Setup, and Where to Actually Run It (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

Uptime Kuma installs in about ninety seconds. One container, one volume, one port. That part is genuinely easy, and every guide covers it.

Here is the part that decides whether the install was worth doing: a monitor that lives inside the network it watches cannot tell you that network went down. Put Kuma on your Proxmox box, point it at your NAS, your Jellyfin, your reverse proxy, and go to bed happy. Then the UPS gives up at 3am. Everything stops, including Kuma. Your phone stays quiet all night, because the thing whose job was to shout is on the floor with everything else.

You find out at 9am. The dashboard shows a clean green wall, because it has no memory of the hours it spent unpowered, and a gap in the record renders identically to a stretch of perfect health once the container comes back and resumes drawing bars.

I have watched people run this setup for months and conclude their homelab is extremely reliable. It wasn’t.

The install, briefly

Version 2.5.0 shipped on 1 August 2026. Pin the major tag.

services:
 uptime-kuma:
 image: louislam/uptime-kuma:2
 container_name: uptime-kuma
 restart: unless-stopped
 ports:
 - "3001:3001"
 volumes:
 - ./data:/app/data

mkdir -p /opt/uptime-kuma/data && cd /opt/uptime-kuma
docker compose up -d

Open port 3001 and create the admin account on first load. That’s it. There is no separate database container. Kuma uses SQLite inside that one data volume, which is why this compose file is four lines of service definition instead of the five-container arrangement a Paperless-ngx stack needs. Version 2.x can talk to other backends for large deployments. For a homelab watching a few dozen endpoints, SQLite is correct and it is one fewer thing that can fail at 3am.

Do not publish 3001 to the internet. It is a login page standing in front of a complete map of your infrastructure, including hostnames and internal ports you would rather not advertise. Put it behind Nginx Proxy Manager or reach it over a WireGuard or Tailscale tunnel.

That is the whole tutorial. The rest of this page is about placement, which is where the value is.

Why placement is the whole problem

Uptime Kuma measures reachability. It sends a request and reports whether something answered. Every result it produces is therefore relative to one specific position on the network — its own.

From inside your LAN, Kuma can see that Jellyfin’s container is answering on port 8096. That is a real and useful fact. It is not the fact your users have. Your users are outside, and between them and Jellyfin sits your ISP, your modem, your router’s NAT and port forwarding, your DNS records, your certificate expiry, and your reverse proxy. Kuma checking http://192.168.1.40:8096 validates exactly one link in that chain and silently vouches for the rest.

So there are two distinct failure classes. One monitor position cannot cover both, and the table below is the reason I stopped treating a single green dashboard as evidence of anything.

Failure	Seen from inside	Seen from outside
Container crashed	yes	yes
Disk full, service refusing writes	yes	yes
Certificate expired	no	yes
DNS record wrong or lapsed	no	yes
ISP down, modem dead, power cut	no — monitor is down too	yes
Port forward removed by a firmware update	no	yes
VPN tunnel to the monitor collapsed	n/a	shows as a false outage

The bottom-left cell is the one that matters. When the whole site loses power, an internal monitor does not report an outage. It reports nothing at all, and nothing looks exactly like fine.

Two placements that work

Primary outside, pointed in. Run Kuma on a small external host and monitor your public endpoints the way a stranger would. This is the setup I would pick if I were only running one instance. It catches expired certificates, broken DNS, dead port forwards, and total site loss, because it is not standing on any of the things that break. Requirements are modest, which is the useful part: Kuma is a single Node process with a SQLite file, so the smallest tier at any VPS host is enough to watch a homelab’s worth of endpoints.

The trade is real. An outside instance sees only what you publish, so anything you never exposed to the internet is invisible to it, and that is usually most of the stack.

Two instances, watching each other. Keep the detailed instance inside, where it can reach every container and internal port. Add a second, nearly empty instance outside whose entire job is to watch the first one and a couple of public endpoints. Point each at the other’s health endpoint. Now an outage has to take out two separate sites and two separate uplinks before you hear silence.

This is the arrangement I would run for anything I actually cared about, and it costs one small VPS.

Do not try to solve this by having the outside instance reach in over a tunnel to check internal services. It sounds tidy. It fails badly, and in a specific way: the tunnel becomes a shared dependency, so every tunnel hiccup fires as a simultaneous outage across a dozen unrelated monitors, and after two weeks of that you will start ignoring the alerts. Which is worse than not having them.

The push monitor is the one people skip

Most Kuma monitors ask a question outward. The push monitor inverts that — it hands you a URL and waits to be called.

# at the end of your backup script
restic backup /data --repo "$REPO" && curl -fsS "$KUMA_PUSH_URL"

If the script finishes, Kuma hears from it. Good. If the script fails, hangs, or was never scheduled because the cron entry got clobbered, the call never arrives and Kuma alerts on the silence.

This catches a class of problem that no reachability check will ever see. Your backup host can be up, healthy, answering pings, and passing every HTTP check while quietly not having produced a backup in five weeks. I would put a push monitor on every scheduled job whose failure you would not notice for a month. Backups first.

Notification settings that avoid making you ignore it

The defaults are tuned to demonstrate the feature, not to survive contact with a homelab that reboots.

Set Heartbeat Interval to how fast you could genuinely respond. Sixty seconds is a reasonable floor. Set Retries to at least 3 before a monitor is marked down, so a container restart does not page you. Sixty seconds with 3 retries gives a service three minutes to come back on its own, which covers nearly every routine restart.

Add at least two notification channels through different infrastructure. Kuma supports over ninety providers. The reason for two is narrow but real: if you route everything through one service and that service is the thing that broke, your alert about the outage is part of the outage.

Then leave it alone for a week and count how many notifications you received that you did not act on. Every one of those is training you to dismiss the next one. Raise the retries until that count is near zero.

The status page, and whether you need a domain

Kuma’s status pages are genuinely good and cost nothing to set up. Group your monitors, mark which ones are public, and publish.

You need a hostname for it if the audience is anyone other than you. A status page at an IP address with a certificate warning does not reassure the household that the media server is coming back. If you are already buying a domain for your reverse proxy, a status. subdomain on it is free and takes about two minutes.

If the audience is only you, skip the domain and reach it over the tunnel.

What I have not tested

I have not run Kuma at a scale where SQLite is the constraint, so I cannot tell you where that boundary sits or whether moving to MariaDB is worth the extra container. Everything above is from homelab-scale use — dozens of monitors, not hundreds.

I have not measured Kuma’s resource use on the very smallest VPS tiers, and I would rather say that than quote a RAM figure I did not take. It is a single Node process with a SQLite file, so the tier below whatever you were considering is probably fine, but “probably” is doing real work in that sentence.

The 2.x non-SQLite backends I have not touched at all.

What getting this wrong costs

A silent monitor is worse than no monitor, because it converts an unknown into a false negative. You stop checking manually. You stop being suspicious. Then a drive fails in a mirror and the array runs degraded for three weeks, and the second drive fails, and the honest answer to “when did this start” is that nobody knows.

The install is ninety seconds. The placement decision is the part that determines whether any of it works, and it is the part almost every guide leaves out — including, for about a year, mine.

GPU Fans Stuck at 100%: The Fix Order That Finds the Cause

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

Fans pinned at 100% feel like an emergency because of the noise, but the noise is the least informative part. A modern card only commands full speed for a handful of reasons, most of them software, and the fastest path out is to check them in the order below — cheapest and most common first — instead of opening the case with a screwdriver on cause number six.

First: two situations where full speed is correct

Before the driver loads. From power-on until the graphics driver initializes, there is no fan-control logic running, and many boards default the fans high or to maximum as a failsafe. Loud at the BIOS screen, quiet at the desktop is normal behavior, not a fault.

When the card is genuinely at its limit. If a monitoring tool shows the hotspot or memory-junction sensor high while the fans scream, the controller is doing its job and your problem is cooling, not control — repaste, airflow, or dust, covered in that guide. Everything below assumes the temperatures are unremarkable while the fans are not.

The fix order

1. Reboot once, properly

A full shutdown and cold boot clears a one-off controller glitch and re-runs the driver’s fan initialization. If the fans come back under control and it never recurs, stop here. If it recurs, the reboot was a clue, not a fix — keep going.

2. Find the fight between fan-control programs

Count everything on the machine that can touch GPU fans: MSI Afterburner, the card vendor’s utility (Armoury Crate, Adrenalin’s tuning tab, iCUE, and friends), and motherboard suites. Two controllers arguing over one card routinely ends with a curve pinned at an extreme. Pick one owner, disable GPU fan control everywhere else, then set that one program’s curve back to its default profile. While you are in there, check for a forgotten manual override — a fixed-speed toggle left at 100% behaves exactly like this and survives reboots.

3. Reset the curve itself

If the single remaining controller still pins the fans, its stored curve or the card’s fan table may be corrupt. Reset the utility to defaults (or uninstall it and let the driver’s automatic control take over). On cards with a dual-BIOS switch, confirm it did not get bumped to the performance position, which runs a deliberately aggressive curve on some models.

4. Rule out the driver-crash fallback

A hung or crashed driver can leave the card with no one steering — and the failsafe is full speed, the same as before boot. If the pinning started after a driver update, or fans max out mid-session while the screen stutters or recovers, do a clean reinstall with DDU in Safe Mode per the GPU driver crash guide. Install the previous stable driver if the newest one is when the trouble began.

5. Check what the sensors are actually reporting

Open a monitor that shows every GPU sensor, not just the core. A controller reacting to a hotspot or memory sensor you were not watching is case “working as designed” from the first section. But a sensor reading that is obviously wrong — a temperature pinned at an impossible value while the others sit normal — means the controller is acting on bad input, which on most cards is a warranty conversation rather than a settings fix.

6. Suspect the fan that reads zero

If one fan reports 0 RPM under load while its neighbors run flat out, the controller may be compensating for a fan it believes has died — and the dead fan (or its tachometer wire) is the real fault. Confirm visually under load: a fan commanded to spin that stands still is the answer. Individual replacement fans exist for most current cards, and swapping one is far cheaper than living at 100%.

After it is fixed

Set the curve somewhere sane and quiet — the diagram above is the shape to aim for: silent below the zero-RPM threshold, smooth ramp through the middle, maximum held in reserve for genuine trouble. If what pushed you here was noise generally, an undervolt cuts the heat the curve responds to, and if the sound that remains is an electronic whine rather than airflow, that is coil whine — a different animal with its own page. And if your problem is the opposite one, read GPU fans not spinning instead.

MXFP4 vs Q4_K_M: Why 21B Beats 14B on an RTX 5080

LK Wood IV — Thu, 13 Aug 2026 09:05:00 -0500

The strangest row in our RTX 5080 throughput dataset is the one where the biggest model is not the slowest. gpt-oss 20B — 20.9B parameters as ollama reports it — decodes at 187–190 tokens per second. Qwen 2.5 14B, six billion parameters smaller, manages 94–97. The “bigger” model is twice as fast, and it lands within a few percent of the dense 7B. None of that is a fluke, and the explanation is worth having because it changes which models you should even shortlist on a 16GB card.

The numbers, and where they come from

Everything below is from our own bench: ollama 0.32.1 on a retail RTX 5080 (driver 610.88), medians of three fresh-prefill runs per cell, model digests pinned, with a nonce prepended each rep so the prompt cache cannot fake the prefill numbers. The full matrix, method, and raw CSV are on the dataset page.

Model	Params	Quant	Decode tok/s	Resident VRAM
Llama 3.2 3B	3.2B	Q4_K_M	298–313	~5.4GiB
gpt-oss 20B	20.9B	MXFP4	187–190	~13.7–14.0GiB
Qwen 2.5 7B	7.6B	Q4_K_M	177–180	~6.0–6.9GiB
Qwen 2.5 14B	14.8B	Q4_K_M	94–97	~10.6–12.8GiB

Decode is a memory race, and only active bytes run it

Generating a token means streaming the model’s weights through the GPU once. Do that a hundred times a second and the limiting factor is not compute — it is how fast VRAM can feed the cores. The RTX 5080’s memory bus moves about 960 GB/s. So the ceiling is simple division: bandwidth over bytes-touched-per-token.

Run it for the dense 14B. Q4_K_M stores roughly 4.5–4.8 bits per weight, so 14.8B parameters is about 8.5–8.9GB that every single token must read. 960 ÷ 8.7 ≈ 110 tokens per second as the theoretical ceiling — and the measured 94–97 is about 90% of that. The arithmetic and the measurement agree, which is how you know the model is bandwidth-bound.

Now gpt-oss 20B. It is a mixture-of-experts model: per OpenAI’s model card, 21B total parameters but only about 3.6B active per token, with the expert weights shipped natively in MXFP4 — 4-bit floating point with shared scale factors, the OCP microscaling format. The 21B has to fit in VRAM (hence the ~14GiB resident), but each token only streams the active slice. A few gigabytes per token instead of nine. That is the whole trick, and it is why the 21B model decodes like a 7B — because per token, it approximately is one.

Total parameters decide whether a model fits. Active bytes decide how fast it runs. Those are different questions, and the spec sheets only advertise the first.

What context length actually costs

The other quietly useful result: at prompts of ~500 and ~1,700 tokens, decode speed was flat between num_ctx 4096 and 16384 for every model — within about 1%. The 16k configurations cost VRAM (the KV cache has to live somewhere) but not speed at these lengths. If you have been keeping context small to protect tokens per second, at normal prompt sizes you are paying a real capacity price for an imaginary speed benefit. Push into genuinely long prompts and attention will eventually take its cut — but that boundary is much further out than the folk wisdom says.

Prefill tells the same story from the other side: it is compute-bound and parallel, and gpt-oss chewed through prompts at 9,000–10,500 tokens per second, roughly double the dense 14B there too.

What to shortlist on a 16GB card

If you want the strongest model that still feels instant on this class of hardware, the measured answer is the MoE: gpt-oss 20B gives 14B-and-up class capability at dense-7B interactive speed, for about 14GiB of resident VRAM. The dense 14B is the choice when a specific dense model’s quality on your task justifies half the speed. And the 3B remains the bulk-work option — 300 tokens per second is a different kind of tool.

Where your GPU lands if it is not a 5080: the local LLM by GPU VRAM guide maps models to cards, the LLM speed calculator estimates decode from bandwidth and quant, and the VRAM calculator does the fit math. What running this card 24/7 costs in electricity is measured in the 5080 perf-per-watt piece.

The dataset behind every number here is CC BY 4.0 — take it: /data/rtx-5080-llm-throughput/.

Coil Whine Database: Per-Model Community Census (GPU, PSU, AIO)

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

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

The short version

Coil whine is one of the most-asked PC noise questions with the least data behind it. As of an August 2026 check, no per-model coil whine database existed anywhere — community knowledge lives in scattered forum threads, plus one lab analysis (hwcooling.net) that measured a 30-card batch once and stopped. Meanwhile “coil whine” draws about 2,900 searches a month and “gpu coil whine” another 1,000 (Google Ads exact match, checked 2026-08-12). This page opens the census that should exist: owner reports of GPUs, PSUs, and AIO pumps on an anchored 0-4 severity scale, published as per-model distributions.

The raw data, schema, and intake all live in the open repository: github.com/iBlessi/coil-whine-db (CC BY 4.0).

Why distributions, never verdicts

The defining fact about coil whine is the design constraint for the whole dataset: it varies unit to unit. The same GPU model ships silent units and screaming units, because the outcome depends on which inductors a particular board received, how they were potted, the PSU feeding them, and the load pattern — not on the model name. A review unit that stays quiet proves nothing about the unit you will receive, and one loud unit on a forum proves nothing about the model.

So the honest per-model answer is never “the RTX 4090 whines” or “it doesn’t.” It is a distribution: out of n reported units, this share was inaudible, this share was audible at the desk, this share screamed even at idle. That is what this database publishes — odds, never verdicts.

The schema

One row = one physical unit an owner listened to. Full machine-readable definitions live in schema.json.

Field	Required	What it records
`component_type`	yes	`gpu`, `psu`, or `aio-pump`
`brand`	yes	As printed on the box — ASUS, Corsair, Arctic
`model`	yes	Model line, specific enough to group units — “ROG Strix RTX 4090”, “RM850x (2021)”
`exact_sku`	no	Exact manufacturer SKU when known
`purchase_year`	yes	Year this unit was bought
`severity`	yes	0–4 on the anchored scale below
`load_context`	yes	Where the score was observed: `idle`, `gaming`, `menu-uncapped-fps`, `furmark`
`psu_used`	no	For GPU reports: the PSU in the system — whine sometimes moves with it
`fps_cap_changes_it`	no	Whether capping FPS audibly changes it — `true` / `false` / untested
`notes`	no	Free text, max 280 characters
`submitted_date`	yes	ISO date of the report

The severity scale (anchored)

Severity	Anchor
0	Inaudible in a quiet room
1	Audible with an ear at the case
2	Audible at the desk under load
3	Audible across the room under load
4	Audible even at idle

Score the unit at its loudest normal state. The anchors are fixed on purpose: changing them would make old and new rows incomparable, so any future anchor change bumps the dataset’s major version instead of quietly redefining the numbers.

How to submit a unit

One report = one physical unit you own or owned, judged by your own ears — not a model you read about. Severity-0 reports (“mine is silent”) are the most valuable rows in the census, because they are the half of the distribution that never shows up in forum threads.

No git knowledge needed — fill in the coil whine report issue form. It mirrors the schema field-for-field; a maintainer transcribes accepted reports into the CSV, with submitted_date taken from the issue’s creation date.
The CSV path — add one row to data/submissions.csv following the schema, and open a pull request. A stdlib validator runs on every PR and blocks malformed rows.

Every submission passes two layers before it lands: the mechanical schema check, and a maintainer review for outlier and troll patterns — duplicate-account bursts filing the same model at the same severity, impossible combinations like a purchase year before the model existed, and rows that summarize other people’s threads instead of a unit the submitter heard. The full acceptance rules are in CONTRIBUTING.md.

What publishes as the census grows

The activation floor, stated verbatim: per-model n + severity distribution once a model has >=5 reports. Below that floor a model is listed as collecting, with no numbers attached. As models cross the floor, their distributions render on this page — n first, then the share of reports at each severity level, always with the sample size in the same breath as the percentages.

The census opened at 0 rows by design — a dataset about unit-to-unit variance cannot be seeded from published reviews, because each review describes a single unit that is not ours to report. Every row is a real owner reporting a real unit.

Current count: n=1. Submission #1 is the maintainer’s own ASUS ROG Astral RTX 5080 OC — severity 1, audible only in uncapped game menus, silenced by any frame cap. It is the same physical card behind the Astral 5080 bench dataset, so its provenance is already public. One report proves the pipeline, not a distribution: the ROG Astral RTX 5080 OC is listed as collecting until it reaches n=5.

The honesty rules

No verdicts below n = 5. A model with three angry reports is collecting, not “a whiner.”
Self-selection bias is named, not hidden. People annoyed by a noise go looking for a place to report it; people with silent units mostly don’t. Annoyed owners over-report and silent units under-report, so every published whine percentage is a ceiling, not an unbiased estimate. The severity-0 row exists to shrink that bias, not to pretend it away.
Anchors never drift. The 0–4 scale above is frozen; a change would be a new major version, and old rows would be marked as scored on the old scale.

Use the data (CC BY 4.0)

The live dataset is one file: data/submissions.csv — one row per reported unit, in the schema order above. License: Creative Commons Attribution 4.0. Attribute as “TechFuelHQ Community Coil Whine Census” linking to this page.

If the noise is bothering you today, the diagnosis and mitigation walkthrough is the coil whine guide: is it normal, and where is it coming from? — and a brand-new buzz paired with crashes belongs in the PSU failure symptoms guide rather than a census form. If capping FPS quiets your card and you want the deeper fix, the GPU undervolt settings database is the companion dataset.

Change log

0.1.0 (2026-08-12) — schema, anchored severity scale, intake (issue form + PR path), validator, and the empty census opened: 0 rows, no seeded data.
0.1.1 (2026-08-13) — first accepted report: the maintainer’s own Astral RTX 5080 OC via the issue-form flow (issue #1 -> validated row). n=1; every model remains below the n>=5 distribution floor.

DDR5 RAM Price Index: Dated $/GB from Direct US Retailers (Pilot)

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

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

The short version

DDR5 prices roughly tripled during the 2026 memory supply crisis, and the numbers that circulate are mostly screenshots without dates or methods. This page is the start of a dated, checkable record: a $/GB index for mainstream 32GB (2x16GB) DDR5 kits observed at named direct US retailers only, with the method, the acceptance rules, every rejection reason, and the raw data published alongside the numbers.

It is labeled a pilot because the index metric has an activation gate it has not passed yet — and rather than loosen the rules to manufacture a number, the gate status is printed here verbatim.

Day-one observations (2026-08-12)

Kit	Cheapest qualifying offer	$/GB	Retailer
Corsair Vengeance 32GB (2x16) DDR5-6000 CL30	$449.99	$14.06	B&H
Corsair Vengeance RGB 32GB (2x16) DDR5-6000 CL30	$449.99	$14.06	B&H
Corsair Dominator Titanium 32GB (2x16) DDR5-6000	$649.99	$20.31	Newegg

21 qualifying offers total across 3 kits, out of 546 listings reviewed. For scale: the Vengeance 6000 CL30 kit was a $95–110 street-price part through 2024 — today’s cheapest direct-retailer offer is roughly 4x that.

Day two (2026-08-13) held the pattern: 581 listings reviewed, 23 qualifying offers, the same 3 Corsair kits, cheapest offer unchanged at $449.99. Day three (2026-08-14) — the capture the table below renders — held it again: 24 qualifying offers across the same 3 Corsair kits, cheapest still $449.99 ($14.06/GB) at B&H, Dominator Titanium still $649.99.

Every qualifying observation, latest capture

The most recent daily capture’s full qualifying set, exactly as the collector recorded it — not just the cheapest row per kit.

Capture Date Utc	Product Label	Title	Seller	Price Usd	Usd per Gb	Verification Status
2026-08-16	Corsair Dominator Titanium 32GB (2x16GB) DDR5-6000 CL30	CORSAIR - Dominator Titanium 32GB (2 x 16GB) DDR5 6000 (PC5 48000) Desktop Memory Model CMP32GX5M2B6000C30 - Black	Best Buy	649.99	20.312	discovery_only
2026-08-16	Corsair Dominator Titanium 32GB (2x16GB) DDR5-6000 CL30	Corsair Dominator Titanium RGB DDR5 32GB (2x16GB) 6000MHz CL30 Memory	Newegg.com	649.99	20.312	discovery_only
2026-08-16	Corsair Dominator Titanium 32GB (2x16GB) DDR5-6000 CL30	CORSAIR Dominator Titanium 32GB (2 x 16GB) DDR5 6000 (PC5 48000) Desktop Memory Model CMP32GX5M2B6000C30W	Newegg.com	649.99	20.312	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	CORSAIR 32GB VENGEANCE RGB DDR5 6000 MT/s DIMM Memory Kit (Gray, 2 x 16GB)	B&H Photo-Video-Audio	449.99	14.062	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	CORSAIR - VENGEANCE RGB DDR5 32GB (2 x 16GB) DDR5 6000MHz CL38-44-44-96 1.35V Intel XMP & AMD EXPO - Gray	Best Buy	449.99	14.062	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	CORSAIR - VENGEANCE 32GB (2x16GB) DDR5 6000MHz C36 UDIMM Desktop Memory - Black	Best Buy	479.99	15.0	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	CORSAIR - VENGEANCE 32GB (2x16GB) DDR5 6000MHz Z30 AMD EXPO & Intel XMP UDIMM Desktop Memory - Black	Best Buy	499.99	15.625	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Corsair Vengeance DDR5 32GB (2x16GB) 6000MT/s Memory Kit	Newegg.com	505.99	15.812	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Corsair CMK32GX5M2B6000C30 VENGEANCE DDR5 32GB (2x16GB) Memory Kit 6000MT/s 30-36-36-76 XMP 3.0 1.4V Black	Central Computers	529.99	16.562	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	CORSAIR - Vengeance 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMK32GX5M2B6000C30 - Black	Best Buy	539.99	16.875	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	CORSAIR Vengeance 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMK32GX5M2B6000Z30	Newegg.com	539.99	16.875	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	CORSAIR - VENGEANCE RGB 32GB (2x16GB) DDR5 6000MHz C36 UDIMM Desktop Memory - White	Best Buy	599	18.719	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	CORSAIR Vengeance RGB 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Custom Lab Cherry Blossom Desktop Memory Model CMH32GX5M2B6000Z30WCB - Whit	Newegg.com	599.99	18.75	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	CORSAIR - Vengeance 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMK32GX5M2B6000Z30W - White	Best Buy	604.99	18.906	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	CORSAIR Vengeance 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMK32GX5M2B6000Z30W	Newegg.com	604.99	18.906	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	CORSAIR - Vengeance RGB 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMH32GX5M2B6000Z30W - White	Best Buy	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	CORSAIR Vengeance RGB 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMH32GX5M2B6000C30W	Newegg.com	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	CORSAIR Vengeance RGB 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMH32GX5M2B6000C30	Newegg.com	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	CORSAIR 32GB VENGEANCE RGB DDR5 6000 MT/s DIMM Memory Kit (Gray, 2 x 16GB)	B&H Photo-Video-Audio	449.99	14.062	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	CORSAIR - Vengeance RGB 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMH32GX5M2B6000C38 - Black	Best Buy	469.59	14.675	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	CORSAIR Vengeance RGB 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMH32GX5M2E6000C36W	Newegg.com	489.99	15.312	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	CORSAIR VENGEANCE RGB 32GB (2x16GB) DDR5 6000MHz RAM	Altex Electronics	499.99	15.625	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	CORSAIR Vengeance RGB 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMH32GX5M2B6000C38	Newegg.com	509.99	15.937	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	CORSAIR Vengeance RGB 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Custom Lab Cherry Blossom Desktop Memory Model CMH32GX5M2B6000Z30WCB - Whit	Newegg.com	599.99	18.75	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	CORSAIR - Vengeance RGB 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMH32GX5M2B6000Z30W - White	Best Buy	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	CORSAIR - Vengeance RGB 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMH32GX5M2B6000C30W - White	Best Buy	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	CORSAIR Vengeance RGB 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Custom Lab Cherry Blossom Desktop Memory Model CMH32GX5M2B6000Z30CB - Gray	Newegg.com	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	CORSAIR Vengeance RGB 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMH32GX5M2B6000C30	Newegg.com	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	CORSAIR Vengeance RGB 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMH32GX5M2B6000Z30W	Newegg.com	619.99	19.375	discovery_only

Rendered at build time from the raw CSV — the table and the download can never disagree.

Gate status, verbatim: 3 of 12 tracked kits produced qualifying offers; the index metric (median cheapest $/GB across kits) activates at 6. Direct retailer stock is not independently confirmed at the listing page yet, so every row carries verification_status: discovery_only.

What gets rejected, and why that’s the point

Of 546 listings reviewed in the day-one capture, 525 were rejected, each with recorded reasons: marketplace and third-party sellers (the largest bucket), listings that don’t state the 32GB capacity or the 2x16GB split in the title, wrong speed for the tracked SKU, used/renewed condition, and prices outside a sanity band. A price index built on listings a script guessed about would be smoother — and worthless. The rejection log ships with the dataset.

Method, exactly

Captures run against Google Shopping (US, English) via DataForSEO’s merchant API, one exact-model query per tracked kit. An offer qualifies only if the seller matches a named direct-retailer allowlist (Best Buy, Newegg, B&H, Micro Center, Adorama, Walmart first-party, and peers — marketplace suffixes excluded), the title states the exact kit line, speed, 32GB capacity, and 2x16GB split (a “Dual Channel” declaration on a 32GB listing counts as the split), condition is new, and the USD price sits inside a $60–900 band. The band’s ceiling was raised from $500 on day one when real direct-retailer offers at $469–499 for the cheapest kit proved the old ceiling was written for a market that no longer exists — that correction is recorded in the change log, not hidden.

Amazon is excluded by design (see FAQ). The full collector, product basket, tests, raw responses, and rejection logs are in the site’s repository.

Use the data (CC BY 4.0)

Download the day-one observations: ram-price-observations.csv — one row per qualifying offer, with capture date, kit, price, $/GB, seller, and verification status. Once the activation gate opens, the daily index series publishes at /data/ram-price-index.csv (median cheapest $/GB across kits, one row per UTC day). License: Creative Commons Attribution 4.0 — attribute as “TechFuelHQ DDR5 RAM Price Index” linking to this page.

Context for the crisis itself: the RAM & SSD price crisis explainer and the DDR5 buying guide — the guide’s price-tracking data is what earned this site its first external news citation, and this index is that work made repeatable.

Change log

0.9.2 (2026-08-14) — day-three capture (24 qualifying offers, same 3 Corsair kits, cheapest unchanged at $449.99). Correction: the rendered observation table had advanced to the 2026-08-14 capture while the prose above it still described only days one and two, so a reader met a table dated later than anything the page acknowledged. The prose now names the capture the table actually serves.
0.9.1 (2026-08-13) — day-two capture (581 reviewed / 23 qualifying / 3 kits, cheapest unchanged). The page now renders the full qualifying observation table straight from the raw CSV at build time, so the visible table and the download can never disagree.
0.9.0 (2026-08-12) — pilot capture and method publication. Four method corrections made against measured evidence on day one, all recorded: price ceiling $500 → $900 (285 real listings died on the stale band); “Dual Channel” accepted as an explicit module-split marker (Newegg writes Trident Z5 Neo kits this way); per-product offer de-duplication (a Corsair offer was being consumed and mis-rejected under another kit’s query); basket v1.1 swapped two kits with zero direct-retailer presence (ADATA XPG Lancer, Patriot Viper Venom) for Dominator Titanium 6000 and Flare X5 5600.

HDD Price Index: Dated $/TB for 8TB NAS Drives from Direct US Retailers (Pilot)

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

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

The short version

Consumer NAS drive prices rose roughly 30-50% through the 2026 supply squeeze as WD and Seagate steered nearline output toward AI and cloud buyers, and most of the $/TB numbers that circulate are undated screenshots or grey-market recertified listings quoted as if they were new-drive prices. This page starts a dated, checkable record: a $/TB index for 8TB 3.5-inch internal drives — the mainstream homelab size — observed at named direct US retailers only, with the method, the acceptance rules, every rejection reason, and the raw data published alongside the numbers.

It is labeled a pilot because the index metric has an activation gate it has not passed yet. Day one produced exactly one qualifying observation, and rather than loosen the rules to manufacture a fuller table, the gate status is printed here verbatim.

Day-one observations (2026-08-12)

Drive	Cheapest qualifying offer	$/TB	Retailer
WD Red Pro 8TB NAS (7200 RPM)	$402.99	$50.37	Best Buy

1 qualifying offer across 1 drive line, out of 673 listings reviewed for 12 tracked models (four NAS, two surveillance, two enterprise, three desktop lines, plus IronWolf Pro). For scale: WD Red Pro 8TB listed around $220-240 through most of 2024, so today’s cheapest qualifying offer is roughly 1.7x its pre-squeeze street price.

Gate status, verbatim: 1 of 12 tracked drives produced qualifying offers; the index metric (median cheapest $/TB across drives) activates at 6. The capture’s blocking reasons: “Direct retailer stock status is not independently confirmed.”; “Exact seller capacity/variant must be verified on the retailer page before publication.”; “Only 1 of 12 models produced eligible rows; the minimum is 6.” Every published row carries verification_status: discovery_only.

What gets rejected, and why that’s the point

672 of 673 reviewed listings were rejected, each with recorded machine-readable reasons (a listing can carry several): 583 came from sellers off the direct-retailer allowlist — eBay storefronts, recertified-drive houses, white-label resellers, marketplace suffixes; 202 never stated the 8TB capacity in the title; 130 carried prices outside the sanity band; 55 were multi-packs or bundles; 52 named a sibling line (IronWolf Pro under the IronWolf query, SkyHawk AI under SkyHawk); 33 were external or enclosure products; 5 were used, recertified, or open-box.

The capacity bucket is the HDD-specific finding: direct retailers frequently publish family-level Google Shopping titles — real examples from this capture include “Gold Hard Drive WD” and “Exos 7E10 Hard Drive Seagate” at $399.99 — that never say which capacity the price belongs to. A tracker that guessed would fill its table faster and be worthless. The rejection log ships with the dataset.

Method, exactly

Captures run against Google Shopping (US, English) via DataForSEO’s merchant API, one exact-model query per tracked drive. An offer qualifies only if the seller matches a named direct-retailer allowlist (Best Buy, Newegg, B&H, Micro Center, Adorama, Walmart first-party, and peers — marketplace suffixes excluded), the title states the exact line and the 8TB capacity, no sibling-superset line token appears, the product is a single internal drive (external/enclosure listings and multi-pack markers like “2-Pack”, “2 x”, or “20PK” are rejected), condition is new (used, refurbished, recertified, and white-label all rejected), and the USD price sits inside a $100-600 band.

Two method corrections were made against measured evidence on day one, both recorded in the change log below: the price ceiling was raised from $400 after a real single-drive offer — the WD Red Pro at $402.99 — died on the old band as its only rejection reason, and a multi-pack guard was added in the same pass because pack listings ($599.98 to $1,479.96 for 2- and 4-packs in the same capture) pass every title rule and would otherwise have entered the raised band as fake singles.

Amazon is excluded by design (see FAQ). The full collector, product basket, tests, raw responses, and rejection logs are in the site’s repository.

Use the data (CC BY 4.0)

Download the day-one observations: hdd-price-observations.csv — one row per qualifying offer, with capture date, drive, price, $/TB, seller, and verification status. Once the activation gate opens, the daily index series publishes at /data/hdd-price-index.csv (median cheapest $/TB across drives, one row per UTC day). License: Creative Commons Attribution 4.0 — attribute as “TechFuelHQ HDD Price Index” linking to this page.

Deciding between the drive lines this index tracks? The IronWolf vs IronWolf Pro vs Exos comparison covers workload ratings and warranty, the budget NAS build guide prices whole builds in the drive crunch, and the NAS storage calculator turns raw capacity into usable space under RAID.

Every qualifying observation, latest capture

The pilot’s entire qualifying set — currently one drive. That thinness is the finding, and the table renders from the raw CSV at build time so it updates the moment the data does.

Capture Date Utc	Product Label	Title	Seller	Price Usd	Usd per Tb	Verification Status
2026-08-12	WD Red Pro 8TB NAS (WD8005FFBX)	WD Red Pro 8TB 3.5" 7200RPM SATA III Hard Drive	Best Buy	402.99	50.37	discovery_only

Rendered at build time from the raw CSV — the table and the download can never disagree.

Change log

0.9.0 (2026-08-12) — pilot capture and method publication. Two method corrections made against measured evidence on day one, both recorded: price ceiling $400 → $600 (a genuine WD Red Pro 8TB single at Best Buy, $402.99, was rejected by the stale ceiling as its only failing check), and a multi-pack/bundle guard added alongside the raise (measured leak shapes: “WD 2-Pack 8TB Red Plus” $739.98, “Seagate 8TB BarraCuda (OEM Packaging, 2-Pack)” $599.98, “2 x WD Red Plus 8TB” $699.98, 20-pack IronWolf rows — all state the line and capacity, so only the guard keeps them out of the raised band). Run 2’s results were collected through DataForSEO’s tasks-ready endpoint after a queue-delay timeout; no tasks were re-posted and no rows were lost.

RTX 5080 Local LLM Throughput: Measured Tokens/Second Dataset

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

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

The short version

This is a measured dataset, not a spec-sheet estimate: real decode and prefill tokens/second for local LLMs on the same retail RTX 5080 that runs this site’s open bench dataset. Three models spanning 3B to 20.9B parameters, two context windows, two prompt sizes, three repetitions per cell, ollama’s native counters, temperature 0.

Per-GPU pages exist elsewhere for the RTX 5090, 4090, and 5060 — none for the 5080 when this dataset was first captured (checked 2026-08-12). This page is the 5080 entry, from a card someone actually owns.

The numbers (capture 2026-08-12)

Model	Quant	Context	Decode tok/s	Prefill tok/s	Load ms	VRAM MiB*
gpt-oss:20b (20.9B)	MXFP4	4,096	190.1 / 187.3	9,078 / 10,465	298 / 280	14,067
gpt-oss:20b (20.9B)	MXFP4	16,384	188.6 / 187.7	9,287 / 10,554	299 / 280	14,355
Qwen 2.5 7B (7.6B)	Q4_K_M	4,096	180.0 / 176.8	10,152 / 9,672	130 / 123	6,190
Qwen 2.5 7B (7.6B)	Q4_K_M	16,384	179.7 / 176.6	10,133 / 9,984	128 / 128	7,034
Qwen 2.5 14B (14.8B)	Q4_K_M	4,096	96.7 / 94.5	5,202 / 4,876	183 / 126	10,841
Qwen 2.5 14B (14.8B)	Q4_K_M	16,384	97.0 / 94.6	5,226 / 4,865	131 / 129	13,157
Llama 3.2 3B (3.2B)	Q4_K_M	4,096	312.0 / 298.2	18,197 / 17,681	163 / 156	15,682*
Llama 3.2 3B (3.2B)	Q4_K_M	16,384	312.9 / 298.6	17,886 / 19,397	163 / 158	5,495

Paired values are the ~500-token / ~1,650-token prompt cells. Every value is the median of 3 runs.

*The starred Llama VRAM reading includes gpt-oss:20b still resident from the previous bench — see the FAQ. The 5,495 MiB row is the model alone.

Three readings worth naming:

Decode speed is flat across context at these prompt sizes. 4k to 16k num_ctx moves gpt-oss:20b by less than 2 tok/s. Context capacity costs VRAM (Qwen: 10.6 → 12.8 GiB), not decode speed, until the prompt itself gets long.
The 20B model is the surprise. gpt-oss:20b’s MXFP4 quantization decodes twice as fast as the dense 14B at Q4_K_M and matches the dense 7B — architecture and quantization beat parameter count.
Prefill is not the bottleneck at these sizes. Even the slowest model ingests ~5,000 tok/s; a 1,650-token prompt costs a third of a second.

The standout result has its own explainer now: why the 21B MoE doubles the dense 14B — the bandwidth arithmetic, shown in full against these rows.

Method, exactly

The capture script (in the site repository) drives ollama’s /api/generate and records its native eval_count/eval_duration and prompt_eval_count/prompt_eval_duration — the timers the runtime itself keeps — never wall-clock division. Each repetition prepends a unique nonce so every run pays a full prefill; without it, warm repetitions hit ollama’s prompt cache and report ~60,000 tok/s cache-hit rates that measure nothing (we caught exactly that in the first capture attempt and rejected those rows). Generation is pinned: temperature 0, seed 42, 256-token target output. A cell enters the CSV only when all 3 repetitions pass mechanical checks (enough tokens generated for a stable rate; a genuine full-prompt prefill observed).

Bench environment, recorded per row: NVIDIA GeForce RTX 5080 (16 GiB), driver 610.88, ollama 0.32.1, Windows 11, Ryzen 7 7800X3D. Model identity is pinned by digest in the CSV, because a tag like qwen2.5:14b can silently move.

Limitations, honestly

One retail card, one driver, one runtime. These are this unit’s numbers — silicon lottery, thermals, and runtime version all move results; that is why each row carries its digest, driver, and date instead of claiming to be a universal constant. The VRAM column is whole-GPU nvidia-smi at measurement time (see FAQ). llama.cpp direct, vLLM, and image-generation throughput are planned lanes, not covered yet.

Use the data (CC BY 4.0)

Download the CSV: rtx-5080-llm-throughput.csv. License: Creative Commons Attribution 4.0. Attribute as “TechFuelHQ RTX 5080 LLM Throughput Dataset” linking to this page. Sizing a build for local AI? Pair these measured rows with the LLM VRAM calculator and the LLM speed calculator — the estimators tell you what should fit; this table shows what one real card actually did.

The full matrix, rendered from the raw CSV

Every measured cell, straight from the downloadable file at build time.

Capture Date Utc	Method Version	Gpu	Driver	Ollama Version	Model	Model Digest12	Parameter Size	Quantization	Num Ctx	Prompt Tokens	Reps	Median Decode Tok S	Median Prefill Tok S	Median Load Ms	Vram Resident Mib
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	gpt-oss:20b	17052f91a42e	20.9B	MXFP4	4096	503	3	190.14	9078.28	297.7	14067
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	gpt-oss:20b	17052f91a42e	20.9B	MXFP4	4096	1658	3	187.27	10464.66	279.5	14060
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	gpt-oss:20b	17052f91a42e	20.9B	MXFP4	16384	503	3	188.63	9286.61	299.2	14355
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	gpt-oss:20b	17052f91a42e	20.9B	MXFP4	16384	1658	3	187.73	10554.32	280.2	14355
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	qwen2.5:14b	7cdf5a0187d5	14.8B	Q4_K_M	4096	488	3	96.65	5202.23	182.5	10841
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	qwen2.5:14b	7cdf5a0187d5	14.8B	Q4_K_M	4096	1674	3	94.48	4876.41	125.8	10855
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	qwen2.5:14b	7cdf5a0187d5	14.8B	Q4_K_M	16384	488	3	97.02	5225.96	131.3	13157
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	qwen2.5:14b	7cdf5a0187d5	14.8B	Q4_K_M	16384	1674	3	94.58	4864.67	128.9	13159
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	llama3.2:3b	a80c4f17acd5	3.2B	Q4_K_M	4096	471	3	311.96	18196.57	162.8	15682
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	llama3.2:3b	a80c4f17acd5	3.2B	Q4_K_M	4096	1657	3	298.21	17681.08	156.2	15682
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	llama3.2:3b	a80c4f17acd5	3.2B	Q4_K_M	16384	471	3	312.89	17885.62	162.9	5495
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	llama3.2:3b	a80c4f17acd5	3.2B	Q4_K_M	16384	1657	3	298.59	19397.36	158.0	5501
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	qwen2.5:7b	845dbda0ea48	7.6B	Q4_K_M	4096	488	3	180.02	10152.28	129.8	6190
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	qwen2.5:7b	845dbda0ea48	7.6B	Q4_K_M	4096	1674	3	176.79	9672.39	123.4	6190
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	qwen2.5:7b	845dbda0ea48	7.6B	Q4_K_M	16384	488	3	179.66	10133.1	127.9	7022
2026-08-12	llm-throughput-ollama-v1	NVIDIA GeForce RTX 5080	610.88	0.32.1	qwen2.5:7b	845dbda0ea48	7.6B	Q4_K_M	16384	1674	3	176.61	9984.37	127.7	7034

Rendered at build time from the raw CSV — the table and the download can never disagree.

Change log

1.0.2 (2026-08-14) — VRAM correction, no re-measurement. The prose and FAQ were converting the CSV’s vram_resident_mib column by 1000 and calling the result GiB; every narrative footprint was ~2.4% high. Recomputed at 1024 (gpt-oss:20b is 13.7–14.0 GiB resident, not 14.0–14.4). The measured table was already correct.
1.0.1 (2026-08-12) — added Qwen 2.5 7B (Q4_K_M): 176.6-180.0 tok/s decode, ~10k tok/s prefill, 6.0-6.9 GiB resident measured alone — four models now span 3B-20.9B.
1.0.0 (2026-08-12) — first capture: gpt-oss:20b, Qwen 2.5 14B, Llama 3.2 3B × 4k/16k context × ~500/~1,650-token prompts, 3 reps per cell, ollama 0.32.1, driver 610.88. First-capture defect worth recording: warm-run prompt-cache contamination was detected and eliminated by per-rep nonces before any row entered the dataset.

What DDR5 RAM Actually Costs Right Now: 16GB to 128GB Kit Price Check

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

By LK Wood IV · Published 2026-08-01 · Prices last checked 2026-08-01 · ~9 min read · St. Louis County, MO

Prices last checked: August 1, 2026

Reading Newegg's own DDR5-6000 CL30 listings that morning: a single 16GB module opened at $214.99, a 32GB (2x16GB) kit at $399.99, a 64GB (2x32GB) kit at $869.99, and the cheapest 128GB (2x64GB) kit at $2,999.99. The independent US tracker WhereIsMyRam put the 32GB DDR5-6000 CL30 floor at $400 the same day and showed the market up 13.7% over the prior 30 days.

These are observed listing prices on one dated morning, not a live feed. Every figure below links to the page it came from. For why memory got this expensive, see the 2026 RAM and SSD price crisis; for which specific kit to buy, see the DDR5 buying guide.

If you searched for what a 32GB DDR5-6000 CL30 kit costs, the answer on August 1, 2026 is roughly $400 to $420, with the cheapest listing at $399.99. That is the number this page exists to give you, with the date attached and a link to where it came from, because a memory price without a date is close to useless in 2026.

Below: the same treatment for every capacity tier, the per-gigabyte math that makes one of them a bad deal, what moved last month, and a straight answer on whether to buy now.

16GB: the cheapest entry, and the worst per-gigabyte deal

Some links below are affiliate links; if you buy through them TechFuel HQ may earn a small commission at no extra cost to you. As an Amazon Associate I earn from qualifying purchases. Commissions never influence which products get recommended — see our disclosure.

Newegg’s 16GB DDR5-6000 CL30 listings on August 1, 2026 opened with a single Patriot Viper Venom 16GB module (PVV516G60C30) at $214.99, timings 30-40-40-76 at 1.35V. The cheapest two-stick 16GB kit in that same listing was G.SKILL’s Flare X5 2x8GB at $264.99.

Divide those out and 16GB is the tier that punishes you. The $214.99 module is about $13.44 per gigabyte by my arithmetic. The 32GB kit below is $12.50 per gigabyte. You are paying more per gigabyte for less memory, and the cheapest 16GB option here is a single module rather than a kit, so a two-slot board runs with one of its memory channels empty until you buy a second stick.

Buy 16GB only if the budget is hard-capped and you know the machine’s job. Anything that touches modern games, browser tabs by the dozen, or a container or two has outgrown it. Our breakdown of how much RAM you actually need walks the capacity question by workload rather than by price.

32GB DDR5-6000 CL30: the number most people came for

This is the tier the search traffic is asking about, so here is the full listing spread from Newegg’s DDR5-6000 CL30 results on August 1, 2026:

The XPG LANCER 2x16GB (AX5U6000C3016G-DCLABK) was the cheapest at $399.99, carrying Newegg’s own “lowest price in 30 days” flag. The RGB version of the same kit and Patriot’s Viper Elite 5 2x16GB both listed at $409.99. V-COLOR’s Manta XSky was $419.99. From there the branded tier climbs fast: Team T-Force Delta RGB at $489.99, Corsair Vengeance RGB at $509.99, and G.SKILL’s Trident Z5 Neo RGB at $599.99. Those are list prices; several carried stacking promo codes at the time of the check, so the number at checkout can land below the number on the tile.

That $200 spread between the cheapest and most expensive 32GB CL30 kit is the single most actionable fact on this page. Every kit in it carries the same rated speed and the same rated latency. In a normal market, paying up for a familiar brand is a defensible $30 decision. At current pricing it is a $200 one.

Cross-checking against a second source: WhereIsMyRam’s US price chart listed the DDR5-6000 CL30 32GB minimum at $400 on the same day, within a dollar of Newegg’s floor. The tracker aggregates US retail listings and states that Amazon prices are excluded from its charts, which is why I use it as the independent check here.

Two more figures from that tracker worth knowing before you buy a speed grade: DDR5-6000 CL36 sat at $380 against $400 for CL30, so tightening the timings at 6000 cost about $20 at this capacity. DDR5-6400 CL32 was $390 and DDR5-5600 CL36 was $376.

The live direct-retailer observations behind this section

These rows come from the TechFuelHQ RAM price index collector — named direct US retailers only, marketplace sellers rejected, refreshed by a daily capture and re-rendered here on every build:

Capture Date Utc	Product Label	Seller	Price Usd	Usd per Gb	Verification Status
2026-08-16	Corsair Dominator Titanium 32GB (2x16GB) DDR5-6000 CL30	Best Buy	649.99	20.312	discovery_only
2026-08-16	Corsair Dominator Titanium 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	649.99	20.312	discovery_only
2026-08-16	Corsair Dominator Titanium 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	649.99	20.312	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	B&H Photo-Video-Audio	449.99	14.062	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Best Buy	449.99	14.062	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Best Buy	479.99	15.0	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Best Buy	499.99	15.625	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	505.99	15.812	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Central Computers	529.99	16.562	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Best Buy	539.99	16.875	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	539.99	16.875	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Best Buy	599	18.719	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	599.99	18.75	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Best Buy	604.99	18.906	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	604.99	18.906	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Best Buy	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	B&H Photo-Video-Audio	449.99	14.062	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	Best Buy	469.59	14.675	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	489.99	15.312	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	Altex Electronics	499.99	15.625	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	509.99	15.937	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	599.99	18.75	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	Best Buy	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	Best Buy	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	619.99	19.375	discovery_only
2026-08-16	Corsair Vengeance RGB 32GB (2x16GB) DDR5-6000 CL30	Newegg.com	619.99	19.375	discovery_only

Rendered at build time from the raw CSV — the table and the download can never disagree.

64GB: double the capacity for slightly more than double the money

Newegg’s 64GB DDR5-6000 CL30 listings on August 1, 2026 bottomed out at V-COLOR’s Manta XFinity RGB 2x32GB (TMXFL3260830KWK) at $869.99. G.SKILL’s Trident Z5 Neo RGB was $995.55, Kingston’s FURY Beast $1,049.99, and Corsair’s Vengeance 2x32GB $1,159.99.

At $869.99 the 64GB tier runs about $13.59 per gigabyte, roughly 9% worse per gigabyte than the 32GB kit. So the honest framing is not “64GB costs twice as much as 32GB.” It costs about 2.2 times as much, and the extra 32GB you are buying arrives at a worse rate than the first 32GB did.

Ignore that penalty if a real workload needs the capacity: virtual machines, large video timelines, a local model that spills out of VRAM. Do not accept it to buy 64GB “to be safe” on a gaming build. At these prices, unused capacity is the most expensive thing on a parts list.

128GB: the tier where the math breaks

Two very different products both get sold as 128GB, and the gap between them is enormous.

Going through 2x64GB modules, Newegg’s 128GB DDR5-6000 listings started at V-COLOR’s Manta XFinity RGB at $2,999.99, and note that it is CL32 rather than CL30 (1.35V, 32-45-45-96). G.SKILL’s Flare X5 and Ripjaws S5 2x64GB kits were $3,249.99 at CL34, and the Trident Z5 Neo RGB was $3,299.99. That $2,999.99 entry point is about $23.44 per gigabyte, nearly double the 32GB rate.

Going through four 32GB modules instead, the same 128GB kit search showed A-Tech’s 4x32GB DDR5-5600 CL46 kit at $1,858.33 and Kingston’s FURY Beast 4x32GB DDR5-5200 CL40 at $2,399.99. The A-Tech kit is roughly $14.52 per gigabyte, which puts it back in line with the rest of the ladder and saves about $1,142 against the 2x64GB route.

The catch is real, not theoretical. You give up the 6000 speed grade, you accept looser timings, and you fill all four DIMM slots, which our DDR5 buying guide covers as the configuration that most reliably costs you rated speed. For a workstation or homelab box where capacity is the entire point and memory clock is not, that trade is usually correct. For anything where the RAM speed matters, the 2x64GB premium is what the convenience costs.

What moved over the last month

WhereIsMyRam’s US market summary on August 1, 2026 showed a 7-day change of +0.9% and a 30-day change of +13.7%, across 1,293 in-stock references, and labeled the week a strong upward trend. The tracker follows 2x16GB kits, and the cheapest tracked configuration at any speed was the $376 DDR5-5600 CL36 entry above.

That 30-day figure is a market-wide aggregate across those 1,293 references, not the move on any one kit. The tracked market rose nearly 14% while a buyer waited.

The honest complication comes from the same tracker: at the individual configuration level it describes DDR5-6000 CL30 as trading at its cheapest level in recent weeks, and Newegg flags the $399.99 XPG LANCER as its own lowest price in 30 days. Both are true. Specific SKUs dip inside a rising market when retailers clear individual lines. Read that as a reason to buy a well-priced kit today, not as a tier that keeps falling.

Buy now or wait: the call, and the reasoning

Buy when you need it. Not because prices are good, but because the supply picture that sets them has no near-term fix.

TrendForce’s July 30, 2026 memory outlook puts the DRAM sufficiency ratio at about -1% to -2% for 2026 and expects the supply-demand gap to widen further in 2027, with DRAM prices on an upward trajectory. Its structural explanation matters more than the forecast: HBM manufacturing requires significantly more wafer input than conventional DRAM, so higher wafer starts do not translate proportionally into additional bit output. More fab capacity does not automatically mean more DIMMs.

Notably, TrendForce splits the two halves of the memory market in that same release. NAND flash supply loosens in the second half of 2027 as new capacity arrives and consumer demand stays weak. DRAM does not. If you have been assuming RAM and SSDs recover together, that assumption is now explicitly contradicted by the forecaster.

The independent read agrees. PCWorld’s April 24, 2026 investigation into the softening that showed up in some regional markets argued the dips were inventory and demand-elasticity effects on top of a structurally tight market rather than a real reversal. Analyst Patrick Moorhead, quoted in that piece, expected conditions to start improving in Q4 2027 and said he did not think the market would be, in his words, “normalized until 2030.”

So the timing bet is not “wait a month.” Taking the earlier of those two dates, it is “wait until late 2027.” If your build can genuinely sit idle for five quarters, waiting is defensible. If it cannot, you are paying an option premium on a market two named sources expect to keep climbing.

When NOT to upgrade

The buy-now advice above applies to memory you actually need. It is not an argument for touching a working machine. Four cases where the right move is to leave it alone:

You are on 32GB and nothing is swapping. Open your task manager under your real workload, not while idle. If committed memory sits below your installed capacity, more RAM buys you nothing. At $400 a kit, “future-proofing” is the most expensive placebo in a 2026 build.

You are running DDR4 and it is stable. A DDR4-to-DDR5 move is a platform change: new CPU, new board, new memory. At $399.99 for the 32GB kit, the memory line alone is now one of the largest items in that upgrade. Unless the CPU is the actual bottleneck, that money does more work in a GPU.

You want to go from CL36 to CL30 at the same capacity. The timing difference costs about $20 when you are already buying, per the tracker figures above. Buying a whole replacement kit to get it means paying $400 to retire working memory. Take tighter timings on a purchase you were making anyway, never as a standalone upgrade.

You are adding a second module to reach an odd total. Memory is sold in matched kits because the modules in one are validated to run together at their rated profile; two sticks bought separately carry no such validation. At current prices a pairing that will not hold its rated speed is an expensive experiment. If you need more, buy a matched kit and sell the old one.

For what a build looks like when memory is priced as the fixed cost it has become, our budget AM5 build was specced around this market rather than against it.

How these numbers were checked

Every price on this page was read on August 1, 2026 from a public retail listing page or an independent price tracker, and each one links to the exact page it came from. Newegg listings supplied the per-capacity figures; WhereIsMyRam supplied the independent cross-check and the market movement figures. The per-gigabyte figures are my own division of those listed prices by capacity, shown so you can check the arithmetic.

Two limits, stated plainly. The retailer links are search pages, so they show today’s prices rather than the ones printed here, which means these exact figures are not reproducible later from the link. And these are list prices: promo codes moved several kits below their listed number on the day I checked, so treat every figure here as a ceiling.

There is no first-party bench data on this page and no test bench behind it. This is a dated price observation, which is what the question calls for. Prices at these retailers move daily. Treat the figures here as the shape of the market on the date printed, and confirm the live number at the link before you spend.

The bottom line

As of August 1, 2026, DDR5-6000 CL30 runs about $12.50 per gigabyte at 32GB, $13.44 at 16GB and $13.59 at 64GB. At 128GB the cheapest DDR5-6000 option is a CL32 kit at $23.44 per gigabyte, or about $14.52 if you drop to a 4x32GB DDR5-5600 kit. The 32GB tier is both the volume sweet spot and the best rate on the ladder, which is unusual and worth taking advantage of.

Buy the capacity your workload actually uses, take the cheapest listing that meets your spec rather than the familiar brand, and do not wait for a correction that the supply forecasts do not support. If you are still deciding which specific kit, the DDR5 buying guide has the picks; if you want the full explanation of how memory got here, the price crisis piece has the cause.

Best Hardware for Frigate NVR (2026)

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

By LK Wood IV · Published 2026-07-30 · Updated 2026-07-30 · ~12 min read · St. Louis County, MO

Some retailer links below are Amazon affiliate links; if you buy through them TechFuel HQ may earn a small commission at no extra cost to you. As an Amazon Associate I earn from qualifying purchases. Commissions never influence which products get recommended — see our disclosure.

TL;DR · Frigate hardware, sized by camera count

1–6 cameras, low activity: an Intel N100/N150 mini PC with 16GB RAM. Frigate's own list names the N100-based Beelink EQ13 for "several 1080p cameras with low-medium activity."
6–12 cameras: step to a modern Core i-series box (Frigate names the 1220P and 125H classes) and 16GB.
12+ cameras, high activity: multiple accelerators or a discrete GPU, per Frigate's planning docs.
Skip the Coral. Frigate now says it is "no longer recommended for new Frigate installations" outside low-power edge cases. Use the iGPU via OpenVINO — it's free.
Check AVX before you buy used. Frigate requires AVX+AVX2; Celeron and Pentium parts before 2020's Tiger Lake "typically lack AVX."
The drive is where the money leaks. A 4TB Seagate SkyHawk at $149.99 is $37.50/TB; a 1TB WD Purple at $162.94 costs more for a quarter of the space. Prices dated 2026-07-30.

Requirements and capability wording are quoted from Frigate's own documentation. Prices are a live Amazon US snapshot taken 2026-07-30 and move week to week — check the retailer link before buying. We do not own a Frigate rig and publish no first-party benchmarks here.

Most “Frigate hardware” pages answer a narrower question than the one people actually ask. They list a minimum spec — 4GB, AVX2, an accelerator — and stop. But the thing you actually need to know is how much box do I need for my number of cameras, and that answer is scattered across a docs page, a GitHub discussion, and a Facebook group.

It’s a conspicuous gap. Ask Google right now and its AI Overview summarises the requirements and then closes by asking you for the missing input: “If you tell me how many cameras you plan to use and their resolutions, I can help you pick the right mini PC or processor configuration.” (AI Overview for “frigate hardware requirements”, US/English, observed 2026-07-30; this wording varies between sessions and is not stable.) The machine knows what the table should contain. None of the top-ranking results we checked for that query on 2026-07-30 published it.

So here it is, sized by camera count, with every requirement traced to Frigate’s own documentation, and every price dated and attributed to the listing it came from.

The three gates before you spend anything

AVX and AVX2, or nothing works. Frigate’s planning guide requires “a CPU with AVX + AVX2 instructions.” Most modern processors carry both — but the exception is exactly the hardware people buy for a cheap NVR. Frigate spells it out: “Intel Celeron and Pentium models prior to the 2020 Tiger Lake generation typically lack AVX.” That cheap used mini-desktop with a Celeron is a dead end. Check the specific model on Intel’s ARK before you buy, not after.

Hardware decoding, which is not the same as detection. Frigate’s video decoding docs say “it is highly recommended to use an integrated or discrete GPU for hardware acceleration video decoding in Frigate,” because pulling apart camera streams is the CPU-heavy half of the workload. This is the part people under-buy: they budget for an AI accelerator and forget that decoding eats a CPU alive without an iGPU.

RAM, in three published tiers. Frigate gives real numbers rather than a vague “more is better”:

Tier	Frigate’s wording	What it assumes
4GB	“generally sufficient for a very basic Frigate setup”	A few cameras, plus a dedicated detector
8GB	“should be considered the minimum”	Once enrichments run — face recognition, license plates
16GB	“is highly recommended”	8+ cameras, or heavy enrichment use

Note that Frigate also holds recording cache in /dev/shm, sized separately from the above. Our Frigate NVR storage calculator computes that value alongside the disk estimate, because getting it wrong is a common first-install failure.

The camera-count ladder

Frigate publishes activity-based guidance in its planning docs, and names specific machines in its recommended hardware list. Neither is a buying table on its own. Combined, they are:

Cameras	Activity	Frigate’s guidance	Practical box	Detector
1–6	Low	a single, entry-level AI accelerator is sufficient	Intel N100/N150 mini PC, 16GB	iGPU via OpenVINO
6–12	Moderate	more processing power required	Modern Core i-series (Frigate names 1220P, 125H classes), 16GB	iGPU via OpenVINO
12+	High	multiple entry-level AI accelerators, or a more powerful single unit such as a discrete GPU	Desktop/server CPU + discrete GPU or Hailo	Hailo-8 or dGPU
40+	Commercial	a modern discrete GPU	Server-class, out of scope here	dGPU

Frigate’s own capability notes for the named machines: the Beelink EQ13 (N100) “can run object detection on several 1080p cameras with low-medium activity”; the 1220P class “can handle a large number of 1080p cameras with high activity”; the 125H class “can handle a significant number of 1080p cameras with high activity.”

Activity matters as much as count. Frigate gates object detection behind motion detection, so a quiet scene costs far less to run than a busy one. Six cameras pointed at a quiet side yard is a genuinely different load from six cameras on a busy street, and Frigate’s own tiering is written in those terms — which is why a flat “cameras → CPU” table from any other site is misleading. If your cameras see constant motion, size up one row.

The Coral question, settled by the people who make Frigate

This is where most of the internet is out of date, including the AI Overview’s own sources.

Frigate’s hardware documentation now states plainly: “The Coral is no longer recommended for new Frigate installations, except in deployments with particularly low power requirements or hardware incapable of utilizing alternative AI accelerators for object detection.” Frigate adds that it “will continue to provide support for the Coral TPU for as long as practicably possible,” so nobody with a working Coral is stranded.

Two things follow, and they save real money:

On an Intel box, the free option is the right one. The integrated GPU handles decoding via Quick Sync and runs detection through Frigate’s OpenVINO detector. One chip, both jobs, zero add-in cost. For the 1–12 camera range that covers most homes, this is the whole answer.

Where a dedicated accelerator genuinely helps, it’s Hailo now. Frigate states that it “supports both the Hailo-8 and Hailo-8L AI Acceleration Modules on compatible hardware platforms,” and lists them among its officially supported detectors. They are not cheap — and the price gap against the deprecated part is stark:

Accelerator	Price (2026-07-30)	Status in Frigate’s docs
Coral M.2, Dual Edge TPU	$55.99	“No longer recommended for new installations”
Hailo AI HAT+ (Pi 5), listed at 13 TOPS	$129.99	Supported detector
Hailo-8 M.2, listed at 26 TOPS	$214.99	Supported detector

Yes, the 26 TOPS Hailo-8 costs nearly four times the deprecated Coral, and the 13 TOPS HAT+ about twice. That tension is real, and none of the top-ranking pages we checked on 2026-07-30 resolves it, so here is the resolution: on an Intel machine you buy neither. OpenVINO on the iGPU is already paid for. Reach for a Hailo when you are on hardware with no usable iGPU — a Raspberry Pi 5, say — or when you are past a dozen busy cameras.

One shopping warning. Searching for these modules returns a swamp. In an automated Amazon US product search for “Hailo-8L M.2” on 2026-07-30, the returned listings included a Raspberry Pi case at $94.99, an NVMe adapter HAT at $25.99, and — in paid slots — CNC carbide inserts and a linear-motion stage. Read the title on every listing. The cheapest genuine Hailo-8 module we could verify was $214.99, not the $25.99 that a price sort will happily show you.

Boxes worth buying, priced 2026-07-30

Machine	Why	Specs	Price
GMKtec G3S (entry)	Lowest-cost pick in this table, for 1–4 low-activity cameras — but see the RAM caveat below	N95 · 8GB · 256GB SSD	$249.99
Beelink EQ-series (N150)	Newer N-series part; ships with RAM and storage included	N150 · 12GB LPDDR5 · 500GB	$309
Beelink S12 Pro (best for most)	16GB out of the box — the tier Frigate calls “highly recommended”	N100 · 16GB DDR4 · 500GB	$339

The trap that costs the most money in 2026: barebone boxes. A barebone mini PC with no RAM and no SSD looks like the value play, and it is not. RAM prices rose steeply through the 2026 memory shortage. The sticker on a barebone unit is a down payment — once you add a DDR5 SO-DIMM kit and an NVMe drive, a “cheap” barebone routinely lands above a complete box that shipped with both. Buy the machine that already includes RAM and storage, or buy a used enterprise micro that does. We work through that math in detail in our best mini PCs for a homelab guide.

If your NVR will also be your smart-home hub, the sizing question changes and we cover it separately in best mini PC for Home Assistant — that page is about a Home Assistant box that also watches a few cameras. This page is about a machine whose main job is cameras. If you want both roles isolated on one machine, our Home Assistant on Proxmox guide covers the virtualisation route.

Storage: where the real money leaks

Frigate’s docs are clear on roles. SSDs “are designed with advanced wear-leveling algorithms” and give you a responsive UI and quick clip retrieval — good for the OS and database. For the relentless 24/7 write load of recording, Frigate points at NVR-rated drives like WD Purple and Seagate SkyHawk, “engineered for 24/7 operation and continuous write workloads.”

Then you go shopping and find the pricing is a minefield. Live Amazon US, 2026-07-30:

Drive	Price	Cost per TB
Seagate SkyHawk 4TB (ST4000VXZ16)	$149.99	$37.50
WD Purple 6TB (WD60PURZ)	$289.99	$48.33
WD Purple 4TB (WD44PURZ)	$219	$54.75
WD Purple 3TB (WD33PURZ)	$215	$71.67
WD Purple 1TB (WD11PURZ)	$162.94	$162.94

Read that bottom row twice. The 1TB WD Purple at $162.94 costs more than the 4TB SkyHawk at $149.99 — you can buy four times the capacity for $12.95 less. And at identical 4TB capacity in the same NVR-rated class, the WD Purple carries a 46% premium over the SkyHawk.

Two rules fall out of it, both bounded to these prices. At this pricing, sub-4TB surveillance drives are never the value pick — run the per-TB number before buying a small one; the pattern usually reflects small capacities being stocked for replacement buyers rather than builders. And check both brands at your target capacity every time, because the badge premium moves and neither brand is reliably cheaper.

Three caveats stated plainly. These are single-listing snapshots taken on one day at one retailer, and they look high against pre-2026 street prices — drive prices move faster than we can re-publish, so treat the per-TB column as a method rather than a price list. Model numbers, capacities and the TOPS figures above are as given in the retailer listings on 2026-07-30, not verified against manufacturer spec sheets. And on annual workload rating — often cited as the reason to pay the WD premium — Seagate states that SkyHawk drives “can support workloads up to 180TB per year,” the same figure the WD Purple listing quotes. On that specification the two are equivalent, so it is not a reason to pay 46% more. We have not tested any of these drives; every rating here is the manufacturer’s own. For drive selection beyond surveillance duty, see best NAS hard drives.

Size it before you buy it. Retention days, camera count, resolution, and codec drive the number far more than intuition suggests — going from 1080p to 4K on eight cameras is not a small adjustment. Put your actual numbers into the Frigate NVR storage calculator and buy against the result. It also computes the /dev/shm value Frigate needs, which is the setting most first-time installs get wrong.

Don’t forget the network side

Cameras need power and bandwidth, and PoE switches are budgeted in watts, not ports. A switch with eight PoE ports and a 60W budget will not run eight 15W cameras. Work out the real figure with our PoE budget calculator before ordering, because “8-port PoE” tells you almost nothing about what it can actually power.

What we’d actually buy

Four 1080p cameras on a quiet property: Beelink S12 Pro (N100, 16GB) at $339, OpenVINO on the iGPU, one 4TB SkyHawk at $149.99. No accelerator. Around $490 all-in before cameras.
Eight cameras, mixed activity: the same 16GB tier is Frigate’s “highly recommended” line — stay on it, step the CPU to a Core i-series box, and move to 6TB or dual 4TB drives.
Twelve or more, busy scenes: this is where Frigate’s docs say multiple accelerators or a real GPU, and where a Hailo-8 at $214.99 starts earning its price.

The honest summary: for the majority of home installs, Frigate is not demanding hardware. It’s demanding about two specific things — AVX2 and hardware decoding — and generous about everything else. Most people over-buy the accelerator and under-buy the drive. Do it the other way around.

Sources

Frigate’s own documentation, fetched 2026-07-30:

Recommended hardware — named machines, capability wording, Coral and Hailo status
Planning a new installation — RAM tiers, AVX requirement, camera-count guidance, drive recommendations
Video decoding — hardware acceleration guidance
Object detectors — OpenVINO and Hailo detector configuration

Prices are a live Amazon US snapshot taken 2026-07-30 via automated retail lookup, with product titles read individually to exclude accessories and bundles. Per-TB figures are our arithmetic on those listed prices. We do not own a Frigate installation and publish no first-party benchmarks on this page; all capability claims are Frigate’s own words, quoted and linked.

PSU Tier List 2026: Power Supply Tiers, Every Row Sourced

LK Wood IV — Wed, 29 Jul 2026 00:00:00 -0500

By LK Wood IV · Published 2026-07-29 · ~14 min read · St. Louis County, MO

Search for a PSU tier list right now and the top results include a Linus Tech Tips forum thread whose own title says [OLD], posted in July 2016; the Cultists Network list, whose current revision 17.0g is dated November 2023; and a scattering of YouTube Shorts. Power supplies moved on: ATX 3.1, the revised 12V-2x6 connector, and a generation of refreshed platforms arrived after most of those lists stopped being maintained.

This page is our answer: a tier database of 28 current power supply families, rebuilt from scratch for the ATX 3.x era. It has two rules the old lists never enforced, and one column none of them carry.

The rules: every specification traces to a source linked in its row — the manufacturer’s own page where one is reachable, otherwise the professional review that published the specification — and every tier placement leans on a test linked right next to it, meaning Cybenetics certification data and hands-on reviews from outlets that load-test on real equipment. Where we could not verify something, the cell is blank. Blank beats guessed.

The column nobody else has: what these units do at the low loads a 24/7 homelab actually runs at, where the 80 PLUS badge on the box is silent. More on that below the table.

How the tiers are decided

Tier letters are our editorial call, but they are derived from stated criteria, so you can audit any placement:

Tier S — a top-of-class professional verdict, a 10-year-or-longer warranty, and either elite measured performance or elite efficiency and noise results. These are the units reviewers compare everything else against.
Tier A — excellent units with strong professional verdicts and warranties of at least seven years, held out of S by one real finding: price, a transient-response result, a shorter warranty than the class leaders, or weak light-load efficiency.
Tier B — good units with a caveat you should know before buying: a louder fan profile, an older ATX 3.0 revision still on shelves, a warranty we could not verify, or a rival that simply tests better at the same price.
Tier C — the budget class. Fine choices when right-sized and bought at the right price, with bigger compromises: Bronze certification, fixed cabling, shorter warranties, or weak efficiency at the extremes.
Avoid — reserved for units whose failures a professional outlet has documented and stood behind. Two entries qualify, both cited.

Four housekeeping notes, because honesty about method is the whole point of this page. First, several 2023–2024 lines were silently refreshed from ATX 3.0/12VHPWR to ATX 3.1/12V-2x6; where the professional review covers the older build, the row says which revision the verdict describes. Second, we name a unit’s OEM platform only when the linked review states it — PSU platform attribution is a folklore-rich area and we do not repeat folklore. Third, rows for units with no independent test behind them were left out; the ones we considered and dropped are listed at the bottom of this page.

The fourth note is an exception we want on the record rather than buried. One row — the EVGA SuperNOVA 1000 GT — carries no independent lab test, because no major outlet ever published one for the GT line. It is in the table anyway, in Tier C, because we ran one for an extended period in a working build and published our own long-term review. That is first-party experience, not a lab bench, and its row says so. It is the only row that rests on our own bench rather than an outlet’s, and if that distinction matters more to you than the hands-on account, treat the row as informational.

The 2026 PSU tier list

Filter by the wattage class you are shopping and the price band you can stomach. Every row stays in the page for search engines and AI assistants regardless of filters; the chips only hide rows on your screen.

28 units, every placement sourced updated 2026-07-29 · open data (JSON)

Tier S — the units reviewers benchmark against

Tier S power supplies — each row lists the unit's specification as published by the source linked in that row, and the sourced reason for its placement.
Power supply	Wattages	Standard	Efficiency	Warranty	At 24/7 idle load	Why it is here	Sources
Corsair RMx (2024, ATX 3.1)	750–1000W	ATX 3.112V-2x6	Cybenetics Gold	10 yr	77.2% at 20W and 0.018W standby (Cybenetics, 115V); 89.5% at 100W in KitGuru's 240V testing	KitGuru rated the RM850x (2024) 9/10 with a Must Have award for power quality, build quality and cabling, on a CWT platform. Corsair rates this generation via Cybenetics rather than an 80 PLUS badge (per KitGuru). Cybenetics also measured the lowest standby draw of any ATX unit here.	spec · review
NZXT C850 / C1000 Gold (ATX 3.1)	850–1000W	ATX 3.112V-2x6 600W	80 PLUS GoldCybenetics Goldnoise A	10 yr	Hardware Busters: efficient at light and super-light loads, high even at 2% load (~20W)	Hardware Busters measured the C1000 (CWT CXT platform) at top overall performance for its class, quiet up to ~790W with strong light-load efficiency; KitGuru scored the white version 9/10. Its only recurring criticism is price.	review
FSP Hydro Ti Pro	850–1000W	ATX 3.012VHPWR 600W	80 PLUS TitaniumCybenetics Titaniumnoise A++	10 yr	74.1% at a 20W (2%) load, 0.076W standby, 12.65 dBA average noise (Cybenetics, 1000W unit)	KitGuru scored the in-house FSP Titanium platform 9.5/10. Cybenetics measured a 12.65 dBA average noise level — the quietest unit in this table — alongside a top-tier low-load result, which is exactly what a 24/7 box wants.	spec · review
be quiet! Dark Power 13	750–1000W	ATX 3.112V-2x6	80 PLUS Titanium	10 yr	74.5% at 20W, 0.068W standby (Cybenetics, 115V, 1000W); Club386's own bench measured 72.0% at 20W and 92.5% at 80W	Club386 awarded the Dark Power 13 1000W Recommended for electrical performance, quiet running and thermal management, and Cybenetics measured roughly 18 dBA average noise — near-silent, with a solid mid-pack low-load result. Current pages state ATX 3.1 with native 12V-2x6; the reviewed launch build was ATX 3.0.	spec · review

Tier A — excellent, held out of S by one finding

Tier A power supplies — each row lists the unit's specification as published by the source linked in that row, and the sourced reason for its placement.
Power supply	Wattages	Standard	Efficiency	Warranty	At 24/7 idle load	Why it is here	Sources
Seasonic Vertex GX (ATX 3.1)	750–1200W	ATX 3.112V-2x6	80 PLUS GoldCybenetics Goldnoise A-	12 yr	no published low-load data	Hardware Busters called the Vertex GX-1200 reliable and class-leadingly quiet — the reviewer runs them on his own test benches — while noting CWT-based rivals score 2–4% higher on raw performance and that it costs more. The ATX 3.1 refresh extended the warranty to 12 years, the longest in this table.	spec · review
Corsair HXi (2025, ATX 3.1)	1000–1500W	ATX 3.112V-2x6 cables (2×8-pin feed)	80 PLUS PlatinumCybenetics Platinumnoise A+	10 yr	Above 70% at 2% load (~24W on the 1200W unit) per Hardware Busters; low standby draw	Hardware Busters found the HX1200i (CWT semi-digital) tightly regulated, silent, and full-power-capable at 47C, with iCUE monitoring and per-rail OCP control. Held out of S for a transient response and light-load efficiency that trail the very best at this price. Worth knowing rather than holding against it: there is no native 12V-2x6 header — the 600W GPU cable feeds from two 8-pin sockets, an arrangement the reviewer considers safer.	spec · review
Super Flower Leadex VII (XG / PRO)	750–1300W	ATX 3.116-pin cable (8+8-pin feed)	80 PLUS GoldCybenetics Platinumnoise A-	10 yr	Below 70% at 2% load (~17W) and elevated vampire power (Hardware Busters, PRO 850W) — a gaming-first unit	Hardware Busters names the Leadex VII XG the best-performing 850W unit in its category and rated the PRO’s load regulation superb, on Super Flower’s in-house platform. Docked from S here for the homelab dimension: measured under 70% at a 2% load, high standby draw, and a weak 5VSB rail — plus sky-high inrush current and no native 12V-2x6 header.	review
be quiet! Straight Power 12	750–1500W	ATX 3.112V-2x6	80 PLUS Platinum	10 yr	no published low-load data	XDA Developers rated the 750W unit 9/10 as a solid high-end pick for current AMD, Intel and NVIDIA hardware, with price the main drawback. Platinum-class, 135mm Silent Wings fan, and the current pages carry native 12V-2x6. We found no published light-load measurements for it, so its homelab standing is unproven.	spec · review
Corsair SF Platinum (2024, SFX)SFX	750–1000W	ATX 3.112V-2x6	80 PLUS PlatinumCybenetics Platinum	7 yr	75.7% at 20W, 0.047W standby (Cybenetics, SF750)	KitGuru rated the SF850 9/10 Must Have — high-quality power and stellar build on a Great Wall platform — making this the default SFX answer. Cybenetics measured the SF750 at 75.7% even at a 20W load, strong for a small-form-factor unit. The 7-year warranty (vs 10+ elsewhere) keeps it out of Tier S under our criteria.	spec · review
XPG Core Reactor II	650–1200W	ATX 3.112V-2x6 (current SKU)	80 PLUS GoldCybenetics Platinum	10 yr	71.5% at a 17W (2%) load, 0.040W standby (Cybenetics, 850W)	Tech4Gamers scored the 1200W unit 9.3/10 Recommended as an excellent performance-per-dollar choice on CWT’s upgraded CSZ platform, and Cybenetics measured the 850W at 71.5% down at a 17W (2%) load. Launched as ATX 3.0/12VHPWR; current pages state ATX 3.1 with 12V-2x6.	spec · review

Tier B — good, with a caveat worth knowing

Tier B power supplies — each row lists the unit's specification as published by the source linked in that row, and the sourced reason for its placement.
Power supply	Wattages	Standard	Efficiency	Warranty	At 24/7 idle load	Why it is here	Sources
Seasonic Focus GX (ATX 3.1, V4)	750–1000W	ATX 3.112V-2x6	80 PLUS GoldCybenetics Platinumnoise A-	10 yr	Above 70% at 2% load, but the reviewer called light-load efficiency unsatisfying (Hardware Busters)	The internet’s reflex recommendation now tests mid-pack: Hardware Busters found the GX-850 V4 well built with Cybenetics Platinum efficiency, but concluded the NZXT C850, Corsair RM850x and Leadex VII XG all outperform it, and criticized an aggressive fan profile and a high launch price. Still a sound in-house Seasonic platform with a 10-year warranty.	spec · review
Corsair RMe (ATX 3.1)	750–1200W	ATX 3.112V-2x6	80 PLUS GoldCybenetics Platinumnoise A-	7 yr	69.6% at 20W, 0.049W standby (Cybenetics, 115V) — weak for an always-on box; 89.3% at 100W in KitGuru's 240V testing	KitGuru rated the RM850e (2025, HEC platform) 8/10 Worth Buying — a decent mid-range performer for RTX 5070 Ti-class builds. It gives up measurable ground and three warranty years to its RMx sibling, and Cybenetics measured it at just 69.6% at a 20W load — the weakest 20W result among the tiered units here, and well off its own RMx sibling’s 77.2%.	spec · review
MSI MPG A850G / A1000G PCIE5	850–1000W	ATX 3.112V-2x6 600W	80 PLUS GoldCybenetics Goldnoise Standard++	10 yr	Strong at light and super-light loads per Hardware Busters (exact figures unpublished)	Hardware Busters found the A1000G (CWT CSZ) fairly priced and genuinely ATX 3.1-compliant with a true 12V-2x6 header and strong light-load efficiency, but trailing same-platform rivals like the Toughpower GF3 and Core Reactor II on ripple suppression.	spec · review
MSI MAG A750GLS PCIE5	650–1000W	ATX 3.116-pin 450W	80 PLUS GoldCybenetics Platinumnoise A	—	High efficiency across all load ranges including light loads (Hardware Busters)	Hardware Busters says the A750GLS (Huntkey-built at 650/750W) fixes the A-GL line’s noise problem and takes the performance lead from the Corsair RM750e at an affordable price, measuring Cybenetics Platinum efficiency with an A noise rating. Held at B only because no source we found states its warranty — an odd omission MSI should fix, and the one thing standing between this unit and Tier A. If you want the best cheap Gold unit here, buy this over its older A850GL stablemate.	spec · review
Thermaltake Toughpower GF3	850–1000W	ATX 3.012VHPWR 600W	80 PLUS GoldCybenetics Goldnoise Standard+	10 yr	Highly efficient at light and super-light loads; sub-20 dBA up to 540W (Hardware Busters)	Hardware Busters rated the GF3 1000W (CWT CSZ) a decent ATX 3.0 unit with high build quality that shines at light and super-light loads and stays under 20 dBA up to 540W — but it gets loud beyond that (Cybenetics Standard+) and does not beat the RM1000x. Note a documented cable discrepancy: the review reports Thermaltake documentation putting the bundled 16-pin cable at 450W while the reviewer measured its sense pins configured for 600W. Thermaltake’s current product page states 600W.	spec · review
Thermaltake Toughpower GF A3	750–850W	ATX 3.112V-2x6 450W	80 PLUS GoldCybenetics Platinumnoise A-	10 yr	Below 70% at 2% load (~17W); good at normal light loads (Hardware Busters)	Hardware Busters called the GF A3 850W (HKC-built sample) a worth-considering budget unit: Cybenetics Platinum efficiency and roughly 7 dBA quieter on average than the same-priced MSI MAG A850GL. Its flags: high inrush current, both EPS connectors sharing one cable, and under 70% efficiency at a 2% load.	spec · review
Cooler Master GX III Gold	750–1250W	ATX 3.112V-2x6 600W (3.1 SKU)	80 PLUS GoldCybenetics Platinumnoise Standard++	10 yr	High efficiency in all load ranges incl. light loads (Hardware Busters); CM claims Titanium-level light-load efficiency at 115V	Hardware Busters found the Lite-On-built GX III 850W efficient across all load ranges with a great APFC, but not competitive at the $170 it carried at review time, with weak ATX 3.x transient response and a fan the reviewer doubted would outlast the 10-year warranty. Cooler Master now sells a separate ATX 3.1 SKU with a native 90-degree 12V-2x6.	spec · review
Cooler Master V850 Gold i	750–850W	ATX 3.012VHPWR 450W	80 PLUS GoldCybenetics Platinumnoise Standard++	10 yr	High efficiency on all load ranges incl. super-light loads (Hardware Busters)	Hardware Busters rated the Chicony-built V850i high-performance and high-build-quality with high efficiency at every load range, but called its $185 review-time price stiff against $100–165 rivals and the ‘semi-digital’ branding overstated (only fan control and monitoring are digital).	review
MSI MAG A750GL / A850GL PCIE5	750–850W	ATX 3.016-pin 450W (marked 600W)	80 PLUS Gold	—	Below 70% at 2% load (~17W); platform needs boosting at light loads (Hardware Busters)	Hardware Busters called the A850GL (CWT GPX) decent, compact and well-priced with good ripple suppression — but noisy even at light loads, under 70% efficient at a 2% load, and shipping a 16-pin cable marked 600W that is actually configured for 450W. Warranty is contested (5 years per the review’s spec table, 10 in current retail titles; MSI’s own datasheet omits it), so we print neither.	spec · review
be quiet! Pure Power 12 M	550–1000W	ATX 3.012VHPWR 600W	80 PLUS Gold	10 yr	74.9% at 20W, 81.8% at 40W, 86.3% at 60W (Club386); Cybenetics: 77.0% at 20W at 230V	Club386 concluded the HEC-built 1000W unit performs like a Dark Power in all but name, and its measured 74.9% at a 20W load is one of the better low-load results here — a quiet, homelab-friendly pick from the ATX 3.0/12VHPWR generation, backed by 10 years.	spec · review
Super Flower Leadex III Gold (ATX 3.1)	650–1300W	ATX 3.112V-2x6 on 1000W+ (unconfirmed at 850W)	80 PLUS GoldCybenetics Gold	10 yr	no published low-load data	Vortez gave the 850W GOLD UP an award as the cheapest route into ATX 3.1/PCIe 5.1 at its $139.99 launch price, on Super Flower’s in-house platform with a 10-year warranty. Check the exact SKU before buying: Super Flower’s own catalog page states the native 12V-2x6 cable applies to the 1000W and 1300W models only, and we could not confirm from either source whether the 850W SKU bundles one.	spec · review
Montech Century II Gold	550–1200W	ATX 3.112V-2x6	80 PLUS GoldCybenetics Goldnoise 26.9 dBA avg	10 yr	Passable but not exceptional at very low loads (Tom's Hardware, 1050W)	The budget pick that punches up: Tom’s Hardware gave the 1050W an Editor’s Choice for solid electrical performance at a modest price, and Cybenetics’ own report on the 850W measured ETA Gold with a 26.9 dBA average. Tom’s cautions: a single 12V-2x6, and a young OEM (XWY, founded by ex-HKC engineers). Note Montech’s marketing says Platinum; Cybenetics’ report says Gold — we print the report.	spec · review

Tier C — budget class, fine when right-sized

Tier C power supplies — each row lists the unit's specification as published by the source linked in that row, and the sourced reason for its placement.
Power supply	Wattages	Standard	Efficiency	Warranty	At 24/7 idle load	Why it is here	Sources
XPG Core Reactor II VE	650–850W	ATX 3.112V-2x6	80 PLUS GoldCybenetics Gold	7 yr	72.6% at a 17W (2%) load, 0.016W standby (Cybenetics, 850W)	Tech4Gamers scored the CWT-built Value Edition 8.9/10 as a solid affordable pick performing above its Gold badge. It trades three warranty years (7 vs 10) and some refinement against the non-VE — and posts the lowest measured standby draw of any unit here (0.016W). A strong C, and a genuinely good cheap always-on unit.	spec · review
DeepCool PN750D / PN850D	750–850W	ATX 3.112V-2x6 600W	80 PLUS GoldCybenetics Goldnoise Standard++	10 yr	Below 70% at 2% load; inefficient 5VSB rail (Hardware Busters)	Hardware Busters found the PN850D (CWT GPW budget platform) ATX 3.1-ready with tight load regulation, full power at 47C and a 10-year warranty — but non-modular, louder than 33 dBA on average, under 70% at a 2% load, and at its $90 review-time price too close to better units.	spec · review
Thermaltake Smart BM3 Bronze	550–850W	ATX 3.112V-2x6 300W	80 PLUS Bronze	5 yr	no published low-load data	eTeknix found the BM3 850W hit a sweet spot for a decent gaming PC — semi-modular, compact, cool and quiet, with mid-load efficiency measuring at Silver-to-Gold levels despite the Bronze badge. Its 16-pin tops out at 300W, so pair it with mid-range cards only.	spec · review
Corsair CX750 (2023, non-modular)	550–750W	—	80 PLUS Bronze	5 yr	no published low-load data	PC Guide rates the current non-modular CX750 4/5 as a strong budget choice at the right price, at the cost of efficiency and modularity. No page we found states an ATX 3.x claim or a 16-pin connector for this SKU, so treat it as a classic 8-pin-era budget unit; Corsair’s newer CX-M (2025) refresh is the ATX 3.1 semi-modular sibling.	spec · review
MSI MAG A750BN PCIE5	750W	ATX 2.412VHPWR 300W (fixed cable)	80 PLUS Bronze	—	Gold-level efficiency below ~50% load, dropping to Bronze at high loads (LTT Labs)	Do not let the PCIE5 branding fool you: LTT Labs’ lab test identifies this as an ATX 2.4 unit with a permanently attached 300W 12VHPWR cable and no UVP protection — though it passed their testing and measured Gold-level efficiency below half load. A fine strictly-budget choice if you understand exactly what it is.	spec · review
EVGA SuperNOVA 1000 GT	650–1000W	—4×6+2 PCIe (12VHPWR adapter included)	80 PLUS Gold	10 yr	no published low-load data	The one row here with no independent lab test — no major outlet published one for the GT line — so it rests on first-party experience: we ran one under an RTX 5080 build for an extended period and rated it 4.3/5. Specifications come from EVGA’s launch announcement rather than a live product page, since evga.com no longer serves them. EVGA’s wind-down also means the nominal 10-year warranty may have no service behind it. Clearance or used pricing only, valued as a zero-warranty unit.	our review

A row's review link goes to the test the placement leans on; spec goes to the manufacturer page behind the wattage, standard and warranty figures. Where a manufacturer page was unreachable, the review is the source for both and no spec link appears. Cells we could not source are left blank — blank beats guessed.

Avoid — documented problems, not vibes

Gigabyte GP-P750GM / GP-P850GM

Documented catastrophic-failure pattern: over-power protection set at 120-150% of rating, a sample that exploded during Tom's Hardware testing, and — as reported in that same Tom's Hardware coverage of GamersNexus' investigation — half of a ten-unit GamersNexus sample failing. A revised version exists (new PCB, OPP lowered), but revised stock is externally indistinguishable from pre-fix stock — Tom's Hardware advises against buying unless the production batch is certain.

Documented by: Tom's Hardware (expert response) · Tom's Hardware (revised-unit review)

No-name case-bundled units (exemplar: Equites T500)

Teardown coverage documented a decorative iron block adding fake weight, no input protections including OCP, and a real capability estimated at roughly half the labeled 500W. The class is still sold bundled inside ultra-cheap cases. Buy only safety-certified units from brands that appear in professional test databases.

Documented by: Tom's Hardware · PC Gamer (via Yahoo syndication)

How to read it

Tiers rank quality, not size. A Tier S 750W unit is not “better” for your build than a Tier B 1000W unit if your build needs 1000W. Size first — our PSU wattage calculator does the arithmetic from your actual parts, and our RTX 50-series PSU guide walks the GPU-specific cases, 5070 through 5090. Then use this table to pick the best unit at that wattage.
Standard and connector matter more than they used to. ATX 3.1 with a native 12V-2x6 is the current target for a modern GPU build. 12VHPWR-era units still work — the connector revision improved contact reliability margins, not compatibility. Watch the cable ratings printed in the rows, because the marking and the wiring do not always agree: Hardware Busters found MSI’s MAG A850GL shipping a 16-pin cable marked 600W whose sense pins were configured for 450W, and found the opposite on Thermaltake’s GF3 1000W, where the documented 450W figure sat against a cable the reviewer measured as configured for 600W. Trust a measured review over a printed number.
Warranty is a quality signal. The industry’s best platforms carry 10–12 years because their makers expect them to survive it. A blank warranty cell means none of that unit’s sources stated one — which is itself worth knowing.
Efficiency badges are a floor, not a curve. The certification column describes a unit at its tested load points, which start at 20% for every 80 PLUS level below Titanium. It tells you nothing about the loads an idle machine spends its life at — which is the next section.

If a unit you own is misbehaving — random restarts, black screens under load, coil whine that changed character — the tier list will not diagnose it; our PSU failure symptoms guide walks the actual triage.

The 24/7 homelab dimension nobody’s tier list covers

Here is the gap in every PSU badge on every box. The 80 PLUS program publishes minimum efficiency thresholds at 20%, 50% and 100% of rated load for every level; only Titanium publishes a minimum at 10% load, per Bel Fuse’s published threshold tables. Below the tested points the certification says nothing about how a unit behaves. Intel’s ATX v3 design guide addresses this directly, adding a low-load point at 10W (or 2% of capacity on units above 500W) that requires 60% efficiency and recommends 70% — the guide’s stated reasoning being that desktop idle power has fallen so far since 2005 that power-supply loss now dominates what an idle machine pulls from the wall.

Now put that next to what always-on hardware actually draws. ServeTheHome measured a Minisforum MS-02 Ultra at 19W idle at the wall and a ZimaCube 2 Pro at 25–30W; a typical N100 mini PC runs single digits to low teens. A homelab box spends the overwhelming majority of its hours at exactly the loads the badge never measured.

The measured numbers make the point better than the argument does. Cybenetics publishes full light-load tables for the units it certifies, and down at a genuine idle load, current Gold-and-above 750–1000W units span 68% to 78%:

Unit	Load	Efficiency	Standby draw
be quiet! Pure Power 12 M 1000W	20W	77.8%	0.055W
Corsair RM850x (2024)	20W	77.2%	0.018W
Corsair SF750 Platinum (2024)	20W	75.7%	0.047W
Seasonic Focus GX-750 (ATX 3.1)	20W	74.5%	0.064W
be quiet! Dark Power 13 1000W	20W	74.5%	0.068W
FSP Hydro Ti Pro 1000W	20W (2%)	74.1%	0.076W
XPG Core Reactor II VE 850W	17W (2%)	72.6%	0.016W
MSI MAG A850GL 850W	20W	72.1%	0.055W
XPG Core Reactor II 850W	17W (2%)	71.5%	0.040W
Corsair RM850e	20W	69.6%	0.049W
FSP Hydro G Pro 1000W	20W (2%)	68.0%	0.071W

All figures at 115V, from each unit’s Cybenetics evaluation report (every report linked in Sources). The load column states the exact point measured: Cybenetics’ low-load row is 2% of rated capacity on units above 500W — 20W on a 1000W unit, 17W on an 850W one — and its light-load table also publishes a fixed 20W point. This list covers the units with published Cybenetics light-load data, which is not the same set as the tier table above; the FSP Hydro G Pro is here for the measurement, not as a tiered recommendation.

Two practical conclusions fall out of this table.

Right-size an always-on box even harder than a gaming PC. Fifty watts on a 1000W unit is a 5% load — below every point the badge tested, and near the bottom of every curve above. The same 50W on a smaller quality unit sits meaningfully higher up its curve. Four families in the table reach down to 550W — the Pure Power 12 M, Century II Gold, Smart BM3 and CX750 — and our wattage calculator will tell you whether your parts list fits one. Resist the instinct to buy double.

When the box runs 24/7, pick from the top of the low-load column. The spread above is real but modest — at a 30W idle, the gap between the best and worst rows works out to a handful of watts at the wall. What makes it worth acting on is that an always-on node multiplies those watts by 8,760 hours a year, across every node you run, and the same units that measure well down here tend to be the quieter, better-built ones anyway. Our 24/7 homelab idle power costs breakdown has the measured draws and annual math for the hardware itself; the power cost calculator turns your own wattage and electricity rate into a yearly figure. And if the box matters enough to run 24/7, it matters enough to put behind a properly sized UPS.

One honest boundary: for a gaming desktop that idles a few hours a day, none of this moves your bill meaningfully; a few watts across a few idle hours is noise. This section exists because homelab duty cycles are the inverse of gaming duty cycles: 90-plus percent idle, every day, forever.

Your PSU is not in this table. Here is how to tier it yourself

The database covers 28 current families, so plenty of perfectly good older units are absent. The method behind every row above is reproducible in about five minutes, using the same public sources:

Find it in the Cybenetics database. Search cybenetics.com for the exact model. A per-unit report gives you measured average efficiency, the light-load table this page leans on, noise in dBA, and standby draw — far more than the badge on the box. No listing at all is itself information: it means no independent lab published full-range numbers.
Read what the platform is, from a review rather than a forum. A hands-on review from an outlet that load-tests will name the OEM platform and how it behaved at temperature. If the only thing you can find is a spec sheet and opinions, treat the unit as untested rather than good.
Check the warranty against the class. Current quality platforms run 10–12 years. A 3–5 year warranty on a modern unit is the manufacturer telling you what it expects.
Check the connector against your card. Confirm the 16-pin cable’s actual rating, not its marking — two units in this table have a mismatch between the two.

If it clears all four, it belongs somewhere in Tier A or B whether or not we have listed it. If it fails step one and step two, that is the real warning sign — not a missing tier letter.

The questions builders keep asking

Should I be worried about my PSU’s tier?

If your current unit is running a system it is sized for and behaving normally, no. Tier lists earn their keep at purchase time, when the units in a price bracket look identical on the box. An installed, stable, correctly sized unit from a reputable maker does not become risky because a spreadsheet ranks something else higher.

Is a lower-tier PSU dangerous with a high-end GPU?

Tier C in this table means compromised, not dangerous. Every C row rests on a test — an outlet’s, or in the single flagged case above, ours — and where a protection is missing, the row says so outright: the MSI MAG A750BN’s entry records that LTT Labs found no under-voltage protection, which is the kind of detail you want printed rather than smoothed over. What deserves genuine caution is the Avoid class, where the failures are documented rather than theoretical, and mismatched sizing: a 300W-rated 16-pin cable feeding a 350W card is a real problem no tier letter fixes. Check the connector column, then check your wattage math.

Should I replace a working eight-year-old power supply?

Not on age alone, but the calculus shifts once a unit is well past its warranty. Capacitors degrade with heat and hours, and an old supply that was sized for the card you had in 2018 is often genuinely undersized for a modern one — which is the condition that stresses it hardest. If it is out of warranty, feeding a much bigger GPU than it was bought for, or showing any of the failure symptoms, replace it proactively rather than after it takes something with it. If it is comfortably sized and behaving, leave it alone.

What is deliberately not here

Seasonic Vertex PX, Super Flower Leadex VII Platinum PRO — manufacturer specs verified, but we found no independent lab test of those specific lines. Spec-sheet-only rows do not get tier letters here.
Seasonic Prime TX and be quiet! Dark Power Pro 13 — these now exist only at 1300W and above, a halo class this table does not cover. Both are well-regarded; neither is a mainstream buy.
Montech Century G5 — gone from Montech’s own catalog with no professional review we could find; its successor Century II Gold is in the table instead.
Whole brands, and this is scope rather than judgment — Thermalright, Lian Li, ASUS, Gigabyte’s current lines, Antec, SilverStone and Phanteks are absent because v1.0 research covered the vendors above, not because their units were assessed and rejected. They are first in line for the next revision.
Successor lines we saw but did not verify — be quiet! Dark Power 14 and Pure Power 13 M, MSI’s GS-suffix refreshes beyond the A750GLS, FSP’s ATX 3.1 Hydro refreshes. They join the table when a verifiable test exists; that is what a living database means.
OEM folklore — platform attributions you may have seen elsewhere for units whose linked reviews do not state one.

Revision 1.0 — published 2026-07-29, 28 units. Next scheduled review: October 2026. Corrections and additions are welcome at hello@techfuelhq.com — bring a source and we will check it against the same standard we held ourselves to. The underlying dataset is downloadable as open JSON under CC BY 4.0, and it carries the same revision stamp, so you can diff it against any later version.

Sources

Certification and specification primaries: Intel ATX Version 3 Multi Rail PSU Design Guide, doc 336521 · CLEAResult 80 PLUS program details · Bel Fuse 80 PLUS threshold tables · Cybenetics ETA methodology · Corsair 80 PLUS vs Cybenetics explainer

Low-load measurements: Cybenetics evaluation reports for the Corsair RM850x, Corsair RM850e, Corsair SF750, Seasonic Focus GX-750, MSI MAG A850GL, be quiet! Pure Power 12 M, be quiet! Dark Power 13, FSP Hydro G Pro, FSP Hydro Ti Pro, XPG Core Reactor II, and XPG Core Reactor II VE

Homelab idle draw: ServeTheHome — Minisforum MS-02 Ultra power consumption · ServeTheHome — ZimaCube 2 Pro power consumption · HomeLab Starter power consumption guide · XDA on PSU oversizing and the efficiency curve

Per-unit review and specification sources are linked directly in each table row.

TechFuel HQ

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

Why it is root, concretely

So why does every tutorial recommend it

Why the change does not take effect immediately

The config.json warning nobody explains

What to do instead, honestly

The Docker Desktop exception

What I have not tested

What getting this wrong costs

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

Look before you sweep

What each command removes

The trap that is genuinely real

What I run weekly

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

What I have not tested

What getting it wrong costs

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

The two directions, side by side

Precedence, in the order Docker documents

The silent failures

Secrets do not belong here

What I do

What I have not tested

What getting it wrong costs

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

The compose file

Before you run that: the stable image is old

The volume line

What it deliberately will not do

Security, briefly, because the socket mount deserves it

PUID and PGID

Adopting stacks you already have

What I have not tested

What getting the volume wrong costs

Headscale: Self-Hosting the Tailscale Control Server (2026)

First, the case against doing this

What it does support

The host

The domain

Where this sits against the alternatives

What I have not tested

What getting this wrong costs

Monitor Shadow Problem: Three Different Faults Wearing One Name (2026)

The test that decides everything

The shadow that holds still: your signal path

VGA sits at the top of the list

Every box between the two ends is a suspect

Length, and the one certification that means something

Then the boring physical things

The shadow that only exists in motion

The shadow that fades on its own

The case where the monitor is innocent

What I have not tested

Sources

Ollama in Docker with GPU: Stop Installing CUDA Inside WSL2 (2026)

The two toolkits people conflate

Running it

Where 11434 really listens

Compose, where –gpus does not exist

The WSL2 restriction nobody mentions

Adding Open WebUI

Verifying the GPU is doing the work

What I have not tested

What getting it wrong costs

SSH Port Forwarding: -L, -R, -D and Why Your Reverse Tunnel Only Works Locally (2026)

The -R trap

Fixing it, on the correct side

The two GatewayPorts

-L, properly

-D, the one people underuse

-J, which is not a tunnel at all

“administratively prohibited”

Privileged ports behave differently by direction

Keeping a tunnel alive

Where this stops being the right tool

What I have not tested

What getting it wrong costs

Uptime Kuma Docker Setup, and Where to Actually Run It (2026)