A small tool that watches your containers just had a major version bump, and the change that will get the loudest reaction is the right one. Anonymous access is gone in What’s Up Docker 9.0. There is no fallback. There is no “but my homelab is internal” flag. The team made the call, and I think the call is correct. Here is what else shipped in 9.0, why it matters for self-hosters, and the three things you should do before you upgrade.
What actually changed in 9.0
WUD 9.0 is a bigger release than the version number suggests. The team swapped the database backend, added real user management, rewrote the authentication system, and shipped a proper token model for scripted access. None of those changes are optional. All of them will touch your install.
The database move is the most consequential change for anyone running a long-lived install. WUD used LokiJS, an in-memory JavaScript database with periodic flushes to disk. The store was fast for small workloads, but it had no real schema, no migrations, and no protection against the kind of partial-write corruption that happens when a host loses power mid-flush. Version 9.0 replaces it with SQLite using Drizzle ORM (a TypeScript-first query layer that gives you typed queries against the SQLite engine). For anyone whose WUD install has been quietly logging container updates for years, the upgrade migrates the historical data automatically, and the new database file is something you can back up, copy, and version-control like any other homelab config file.
The auth rewrite is the change most people will actually feel. Pre-9.0 WUD issued a single JWT (JSON Web Token, a signed token format used for stateless sessions) at startup with no revocation, no rotation, and no concept of multiple users. Post-9.0 WUD uses signed session cookies, server-side session storage in SQLite, and a token endpoint that mints personal API tokens with scoped permissions and expiration dates.
Beyond auth and storage, 9.0 also ships a proper role framework. Where pre-9.0 had effectively one role (admin, or no auth at all), 9.0 ships with three roles: Administrator, Read/Write, and Read-Only. The role system is the foundation for the team features the maintainers have on the roadmap.
Anonymous access is gone, and that is the right call
The loudest complaints about 9.0 will be about the removal of anonymous access. Some of them are legitimate. There is no group support yet, so a homelab with five users has to add each one individually. There is no LDAP or OIDC integration yet for shops that already have an identity provider. A CI pipeline that hit the old unauthenticated API needs to be reworked to use a token.
Most of the complaints, though, are about losing a feature that was a security hole with a friendly face. Anonymous access on a tool that watches your container fleet, sits on the same network as your databases, and pings you when an upstream image changes is exactly the kind of attack surface that turns a homelab mistake into a serious incident. If you ever accidentally exposed the WUD dashboard to the internet through a misconfigured reverse proxy, anyone with a browser could see your full container inventory and start triggering updates. Removing anonymous access closes that hole.
The replacement is a real user model. First-run setup creates a default admin account and forces you to set a password. From there you add accounts through the user panel, assign roles, and mint personal tokens from the same interface. If you have been scripting WUD updates against the old API, you mint a token, scope it to read-only or read/write as appropriate, and put it in your script config. The token format is documented, the rotation tooling is built in, and a leaked token can be revoked without touching anyone else’s scripts.
What to do before you upgrade
Four things, in order of importance.
- Back up your existing WUD data volume before you upgrade. The LokiJS-to-SQLite migration is automatic, but it is one-way. If anything goes wrong halfway through, you restore the old volume and start over.
- Mint a personal API token during or right after the upgrade if you script against WUD. The unauthenticated API is gone. Scripts that hit it will start returning 401 immediately after upgrade.
- Pick an admin password you do not use anywhere else. The new auth system is real, and a weak password is now a real exposure rather than a theoretical one.
- Run the upgrade on a test container first if you have the CPU cycles to spare. A copy of your WUD data volume in a test container tells you whether the migration completes cleanly on your specific install before you touch production.
The upgrade itself takes about four minutes on a small homelab, including the database migration and a container restart. If you have years of historical update data, the migration step is the slowest part. Schedule it for a low-traffic window.
What you give up by upgrading
Three trade-offs are worth knowing about.
- The user management panel is functional but bare. There are no groups, no role inheritance, and no identity provider integration yet. If you run WUD in a team setting with more than five users, you will feel this gap.
- The SQLite database grows as you log more history, and there is no built-in rotation or compaction yet. A homelab running daily update checks for a year ends up with a database in the low hundreds of megabytes. Not a problem on a modern disk, but worth knowing.
- The migration is one-way. If the upgrade fails halfway through, you do not roll back without restoring the old data volume from backup. Make sure that backup exists before you start.
You also lose a handful of capabilities outright. Anonymous access is gone for good. The unauthenticated REST API is gone for good. The ability to mount the LokiJS database file directly and query it with JavaScript tooling is gone, replaced by a SQL interface that is faster but requires different tooling. If your automation depended on any of those, the upgrade is a rewrite, not a config change.
Trade-offs
For most homelab users, the upgrade is a clear win. The new auth is more secure. The database is more reliable. The migration is fast. The trade-off you accept is more administrative work up front (set up users, mint tokens, decide who gets which role) for fewer surprises later.
For shops running WUD at scale, the calculus is different. The missing group support and the missing identity provider integration are real blockers. If your WUD install sits behind an enterprise single sign-on, 9.0 does not yet plug into that flow. The maintainers have both on the roadmap, but neither has shipped. Until they do, 9.0 is a foundation for team use, not a finished team product.
The version of myself that ran the upgrade on a Tuesday afternoon without reading the release notes first learned this the hard way. Read the release notes before you hit upgrade. The auth rewrite is real, your old scripts will break, and the only thing worse than a Tuesday afternoon upgrade is a Tuesday afternoon upgrade followed by a Wednesday morning incident.
Bottom line
If you run WUD on a homelab behind a VPN, upgrade. The migration is fast, the new auth is more secure, and the SQLite backend is more reliable than the old in-memory store. Set the admin password on first boot, mint a token for any scripts that hit the API, and forget about it for another year.
If you run WUD at scale or in a team with more than five users, wait for the group support and identity provider integration that the team has on the roadmap. The 9.0 release is the foundation for those features. Upgrade to test, but do not put it in front of real users until those gaps close.