Documentation for many companies, or a directory for one.
Hudu is IT documentation built for managed service providers: one platform holding the assets, credentials, procedures and networks of every client an MSP looks after, wired into the RMM and PSA tools the MSP already runs. MunkiWho is a directory for one organisation's own IT team — who exists, what they belong to, what they can reach, what they hold.
The customer is different before the feature list is, so this page starts by telling you which one you are.
- You look after other companies' IT for a living and need one platform across all of them.
- You need a password vault — shared credentials stored, versioned and retrieved, with one-time codes.
- Your RMM and PSA should feed it automatically, so devices and tickets appear without typing.
- You document networks, racks and procedures with diagrams and rich runbooks.
- Technicians are the unit you buy in, and client contacts need a portal.
- You are one organisation's IT team, and the question is what your own people have.
- Folder permissions matter — who can reach a share, resolved through groups — and no documentation tool models them.
- You would rather generate and send a password than store one.
- Onboarding and offboarding checklists should know who the person is and what they already hold.
- You want unlimited logins for a flat price, so the whole team can look things up.
What each one is for
Green means it does it; red means it does not; amber means partly, with the caveat in the cell.
| Capability | MunkiWho | Hudu |
|---|---|---|
| Built for | One organisation's IT team | MSPs managing many clients |
| Multiple companies in one account | No One workspace, one directory. | Yes — the core |
| Password vault | No MunkiKey generates and sends; it stores nothing. | Yes, with OTP |
| One-time password links | Yes — MunkiKey Sealed in your browser; neither server can read it. | Yes |
| RMM and PSA integrations | No | Yes, many |
| Folder permissions and "who can access this?" | Yes Resolved through nested groups; denies kept separate. | Can be written down, not resolved |
| Groups with nested membership | Yes | Contacts and custom layouts |
| Asset register | Yes, with a maintenance log | Yes, fed by the RMM |
| Software licences with seats and expiry | Yes | Yes |
| Onboarding and offboarding checklists | Yes — per person, with status | Processes and procedures |
| Knowledge base and runbooks | Yes | Yes, richer |
| Network diagrams and rack layouts | No | Yes |
| MCP server for AI assistants | Yes, read-only, nine tools | Via its API |
| Self-hosted | Yes | Yes |
| Priced by | Directory size, unlimited logins | Per technician |
A vault stores passwords. MunkiKey refuses to.
Hudu's password vault is one of the reasons MSPs buy it: hundreds of client credentials, shared safely across technicians, retrievable later. That is a real need and MunkiWho does not meet it. MunkiKey is the other half of the same problem: it generates a password from the browser's random number generator, and sends it as a link that works a set number of times and then stops existing. Nothing is stored — not by you, not by us. A lost link cannot be recovered, and that is the point.
For a single organisation issuing a new starter's first password, or resetting one over the phone, that is usually the whole requirement. For an MSP holding the admin credentials of forty clients, it is not.
Documenting a permission is not the same as resolving one
You can write "Finance group has modify on the Payroll share" into any documentation tool. What you cannot then do is ask it who that is. MunkiWho's folders carry allow and deny entries naming people and groups, and "who can access this?" resolves them through nested membership to a list of people, each once, with the route they came in by. Denies are reported separately, because whether a deny beats an allow depends on the platform the folder is on. That is a data model, not a document, and it is the thing MunkiWho has that a documentation platform does not.
Where Hudu wins, honestly
If you are an MSP, stop reading and buy Hudu. MunkiWho has one directory per workspace and no concept of a client, so running forty companies through it would mean forty logins, and none of the RMM and PSA integrations that make an MSP's documentation fill itself in. The vault, the network diagrams, the rich procedures and the client portal are all things Hudu has and we do not.
Even inside one organisation, a team that documents infrastructure in depth — racks, VLANs, runbooks with embedded diagrams — will find our knowledge base plain by comparison. It is articles and files in folders. That is deliberate, but it is a limit.
Priced by directory size
Unlimited logins on every band — the whole team, not a count of technicians. Full pricing →
Try it with your own list
Import people from CSV, add the groups and folders that matter, and see whether "who can reach this?" comes back with the answer you needed.
Get MunkiWhoQuestions people ask before choosing
We are an MSP. Is there any case for MunkiWho?
Where do we keep shared passwords, then?
Can an AI assistant query it, as with Hudu's API?
All of them are on the comparison index, each one opening with the case for the other product.
Comparison reviewed September 2026 against Hudu's publicly available documentation. Hudu is a trademark of its owner and is used here only to identify the product being compared; MunkiWho is not affiliated with or endorsed by them. Products change — verify anything that matters to your decision on the vendor's own site, and tell us if something here has gone out of date.
Stop guessing who has what.
Set it up in an afternoon, import what you already have, and have an answer next time somebody asks.