The Hunter: Finding the Battleship in Your Canal

A Note That Catches Itself

The note went in on the 7th of July 2026, and it is one of those captures that starts as an idea and ends, mid-sentence, as a confession.

Add to review: authentik and WAHA hunter. When we have a needlessly heavy piece of the stack when other options are much better.

The note goes on to say that this is not only about being heavy on the server. It is also about being overly complicated. And then, in parentheses, it notes that this is itself ironic, and the transcription trails off before finishing the thought.

That unfinished parenthesis is the best part of the note, because the irony is obvious once you see it. The proposal is to build a tool whose job is to find unnecessary tools. A piece of stack whose purpose is to detect excess stack. The snake has noticed its own tail and made a note about it.

But underneath the joke is a real and quite hard question, and it is one that almost nobody answers properly, including the people who write the comparison articles. The question is: how do you know when something in your setup is too big for the job it is doing? Not "does it feel heavy". Not "does someone on a forum say it is bloated". How do you actually know?

The 2 examples named in the note are perfect for this, because they fail the test in completely different ways, and the investigation into them turns up something genuinely alarming about the state of the advice available online.

Heavy Is Three Complaints In One Coat

Before either example, the word needs taking apart, because "heavy" is doing at least 3 different jobs and they pull in different directions.

The first weight is resources. Memory, processor, disk. This is the one everybody quotes, because it is the only one that produces a number, and a number feels like evidence. It is also, for most self-hosted setups in 2026, the least important of the three. Memory is cheap. A server with 8 gigabytes costs less per month than a takeaway pizza, and if the difference between 2 options is 400 megabytes, that difference is real but it is not a reason to spend a weekend migrating.

The second weight is operational. How often does it need attention. How does it upgrade. What happens when it breaks at 11 at night. How many separate processes must all be alive and at compatible versions for the thing to work. This weight almost never appears in comparisons because it does not produce a number, and it is the one that actually determines whether a piece of software is a good citizen in a one-person setup.

The third weight is conceptual. How much do you have to hold in your head to change something. How many concepts does the tool insist you learn before it will do the simple thing. This is the weight that makes people quietly abandon software they have already installed, and it is entirely invisible in any benchmark.

Those 3 weights are not correlated. Something can be featherlight on resources and brutal conceptually. Something can idle at a gigabyte and never require a single thought for 2 years. Anyone hunting for excess needs to say which weight they are hunting, or they will find the wrong things.

The Identity Problem

Take the first name in the note.

The tool in question is an identity provider. It launched in 2020, it is written in Python, and it has grown to somewhere near 20 thousand stars on the main code hosting site, which tells you it solved a real problem for a lot of people. Its distinguishing feature is a visual flow builder: you assemble authentication journeys by clicking, so you can have passwordless login for one group and multi-factor for another without writing code. It speaks all the standard protocols. It provides its own administrative interface, user self-service, directory provisioning, and identity federation.

It also requires a database and a cache and runs as several coordinated processes. For a large organisation, all of that is exactly right and none of it is excess.

The lighter alternative in the same space takes an entirely different approach. Rather than being the system that everything else trusts, it sits beside your reverse proxy and answers one question: is this person allowed through. The proxy intercepts a request, asks, and gets a yes or a no. Users and rules and multi-factor policy live in a single configuration file that you commit to version control. It is designed to put a login wall and a second factor in front of applications that have no authentication of their own, and for that job it is very hard to beat.

The community verdict, gathered across a lot of threads over several years, comes down to one honest line that keeps recurring in different wording: the big one is more capable, the small one is easier. And the migrations run in both directions for opposite reasons. People leave the big one for the small one to cut resource use and shrink the attack surface. People leave the small one for the big one when they get tired of hand-editing configuration and want a graphical interface and per-application control.

That is a healthy market. Neither is wrong. The question the note asks is narrower and better: which one is wrong for this particular setup.

The Numbers Nobody Measured

Here is the part that should genuinely bother anyone who has ever chosen infrastructure by reading comparisons.

An analysis published in July 2026 went looking at the ranking pages that compare these 2 tools, the ones that come up first when you search, and tried to reconcile their resource figures. The lighter tool was quoted as using anywhere from under 30 megabytes of memory at idle to over 1 gigabyte. That is more than a thirtyfold spread. For the same product.

And when the analysis looked for what was behind those figures, it found nothing. Not one of the pages published the configuration used. Not one published the raw output of the command that would have produced the measurement. Not one stated the version. Not one even said whether the number was taken at idle or under load.

Sit with what that means. The single most repeated concrete complaint about a widely deployed piece of software, the number that appears in dozens of articles and gets quoted in forum arguments and decides real migrations, is unsourced. People are moving their authentication infrastructure on the strength of a figure that nobody can trace to a measurement.

This is the actual finding for anyone building a hunter. The hunter cannot be a lookup table of known-heavy software, because the table would be built from these same numbers and would inherit their garbage. The only thing a hunter can honestly report is what it measures on the machine it is running on. Which sounds obvious, and is exactly the thing every comparison article fails to do.

There is a second implication that is easy to miss. If the same software can plausibly idle at 30 megabytes or at a gigabyte depending on how it is configured, then the heaviness is not a property of the software. It is a property of how you deployed it. Which means the correct first move, before any migration, is not to replace the tool. It is to find out what your own instance is actually doing, and then find out why.

The Weight That Actually Hurts

For the identity tool specifically, the resource question turns out to be a distraction, because the operational weight is the interesting one and it is documented rather than rumoured.

Three facts, all from the project's own upgrade documentation. It does not support downgrades. Major version upgrades must be performed sequentially, so an installation that has been left alone for a couple of years cannot jump straight to current and must be walked forward one major version at a time. And if you run separate satellite containers for the proxy or directory functions, those must match the server version exactly.

Read those as one sentence and the shape appears. This is software that will punish you for neglecting it, and it will punish you more the longer you neglect it. There is no rollback if an upgrade goes badly. The debt compounds. And the version coupling means an upgrade is never one container, it is a coordinated move across several.

For a company with a platform team, that is completely normal and entirely manageable. For a person running 3 businesses who touches this thing twice a year, it is a trap with a slow fuse. The bill does not arrive on installation day, when enthusiasm is high and everything works. It arrives 18 months later, on an evening when something is broken and you discover you are 4 major versions behind and cannot skip.

That is the honest case for the lighter option in a one-person setup, and notice that it has nothing to do with memory. A single process configured by one file that lives in your repository has a recovery story you can execute while tired.

The counter-case is equally real and should be stated. If you genuinely need applications to authenticate against a central identity, with proper token issuing and directory provisioning and self-service, then choosing the small tool means building the missing parts yourself, and self-built authentication is the single worst place to be creative. The lighter tool is only lighter if the job is actually the smaller job.

The Second Name On The Note

The other tool named in the capture is a different animal entirely, and the accusation against it is mostly unfair.

It is an HTTP interface for WhatsApp. You run it, you connect a WhatsApp account, and you get a normal web interface for sending and receiving messages, which is enormously useful if you want automation to reach people where they actually read things.

The reason it gets called heavy is that one way of talking to WhatsApp involves running a headless browser. The library underneath drives an actual copy of the WhatsApp web client through browser automation, which means a full Chromium process sitting on your server, consuming memory in the hundreds of megabytes, for the privilege of sending a text message. That is, on its face, an absurd amount of machinery.

But the tool named in the note is not that library. It is a wrapper that supports more than one engine underneath. You can run it over the browser-based engine, or over a completely different engine that speaks the protocol directly over a websocket with no browser at all, and switch between them without rewriting your integration.

That is not bloat. That is a hedge, and it is a well-designed one. The entire category of unofficial WhatsApp tooling exists at the mercy of a protocol that changes without notice, and the single most valuable property such a tool can have is the ability to switch its foundations when one of them breaks. Someone thought carefully about the failure mode and built for it.

So the correct finding for the hunter is not "this is heavy, replace it". It is "this may be running the expensive engine when the cheap one would do, and that is a setting, not a migration". A 30 second configuration change instead of a weekend.

The Rules You Cannot Engineer Around

The WhatsApp case comes with a warning that has nothing to do with weight, and anyone considering this area should hear it before writing a line of code.

Every unofficial library in this space works by pretending to be a normal WhatsApp client using a normal personal number. All of them ship near-identical disclaimers saying they are not affiliated with or endorsed by WhatsApp and cannot guarantee you will not be banned. The ban is not a warning followed by an appeal. It is the number, permanently, and it is the same number that people in your life use to reach you.

The sanctioned alternative is the official business platform, which is compliant, hosted by Meta, and immune to that particular risk. It costs money per message, with the pricing having moved to a per-message model in the middle of 2025, and it requires a real onboarding process with business verification.

And then the detail that changes the whole calculation for personal tooling. From the middle of January 2026, the official platform explicitly prohibits general-purpose assistants, meaning anything that will answer any question on any topic. Only structured bots for defined business functions are permitted: support, bookings, order tracking, that shape of thing.

Which produces an uncomfortable conclusion. If what you want is a business notification channel, the official route is available, compliant, and priced. If what you want is a personal assistant you can talk to over WhatsApp, there is no compliant path at all. The official platform forbids it by policy, and the unofficial route risks the number you actually use. That is not a technical problem with a technical answer. It is a closed door, and the only honest response is to notice it is closed rather than to keep trying handles.

There is a licensing wrinkle too, worth 30 seconds. One of the popular engines is permissively licensed, but it depends on a cryptography library that carries a strong copyleft licence. Running it on your own server for your own purposes is not distribution and triggers nothing. Shipping a product built on it to customers is a different situation with real obligations. Anyone whose personal tool might one day become a product for other people should know which side of that line they are standing on before the tool becomes popular.

What The Hunter Should Actually Do

So what survives of the original idea.

The scanning-for-known-heavy-software version does not survive, because the reference data it would need does not exist in trustworthy form, as the thirtyfold spread demonstrated. Any tool built on those numbers would confidently report fiction.

What does survive is much simpler and much more useful. A thing that looks at what is running on your own machines and answers 3 questions about each piece. What is it consuming right now, measured rather than looked up. When was it last upgraded, and how far behind current is it. And when did anything last actually use it.

That third question is the one that finds real waste, and it is the one nobody asks. The most expensive thing in most self-hosted setups is not the tool that uses too much memory. It is the tool that uses a moderate amount of memory and has not served a request in 7 months, and which everyone has forgotten is even there, and which is now 4 major versions behind and will be a genuine problem the day it is finally noticed. Excess is not usually a battleship in the canal. It is a rowing boat nobody has looked at since spring, slowly filling with water.

A hunter that reported the forgotten services, with a last-used date and a version gap, would earn its keep in the first week. It needs no comparison tables, no opinions about which identity provider is fashionable, and no reference data from anyone else's blog.

The Irony Clause

Which brings the note back to its own unfinished parenthesis.

Yes, a tool that hunts for unnecessary tools is itself a tool, and it is subject to the same audit it performs. The way out of that loop is not cleverness. It is a hard constraint accepted at the start: the hunter must be small enough that it never appears in its own report. No database. No web interface. No separate process that has to be running. A scheduled script that reads what is already there, writes its findings into the inbox that already exists, and has no state of its own worth backing up.

If the hunter needs a dashboard, the hunter has become the thing it was built to find. That is not a joke about recursion. It is a specification, and it is the only one the project really needs.

There is a broader version of this that applies well beyond servers. Every piece of tooling you add to make your work lighter has a maintenance mass of its own, and that mass is invisible on the day you build it and fully visible 6 months later when you are debugging your helper instead of doing the work it was meant to help with. The question is never whether a tool is good. It is whether the tool is smaller than the problem.

Both names in the note pass that test, incidentally, once the accusations are examined properly. The identity provider is not too heavy in memory, it is too heavy in upgrade obligation, which is a different diagnosis with a different treatment. And the messaging bridge is not heavy at all, it is running an expensive engine that can simply be switched, and the real risk there was never resources but a policy that quietly closed the door on the use everybody actually wants.

Which is a good outcome for one afternoon's investigation, and a reminder that the first job of a hunter is to check whether the thing it is chasing is actually there.