A Docker dashboard is one of those pieces of software that you forget about until it breaks. Then you remember every shortcut you took to set it up. Most homelab stacks end up with whatever UI they grabbed first, running for years without anyone asking whether it still deserves the slot. The honest way to think about picking one is to treat it like an evaluation rather than a swap. Five questions catch almost every tool that is going to disappoint you eighteen months in.
What does the dashboard actually own
The first question is the one most homelab guides skip past. Your dashboard is either the source of truth for what runs on your host, or it is a thin window on top of files that already exist on disk. The difference matters because it determines how you recover when the UI breaks, when the developer disappears, or when you simply want to move to a different host.
Portainer stores stacks as objects inside its own database. That gives you a polished interface with app templates, user management, and remote agent support. The trade is that your running containers exist in two places at once: the Compose definition that Portainer keeps internally, and the actual runtime state that Docker sees. When you want to roll back, redeploy from a clean slate, or audit what is running, you go through Portainer. If Portainer breaks or the project loses momentum, that internal database becomes a liability you have to extract.
Tools like Dockge, Cosmos, or a plain text editor plus Portainer’s agent take the other route. They treat the file on disk as the canonical source. The UI reads the file, the UI writes back to the file, and the file is the thing you back up, version control, and move between machines. There is no proprietary export step. The interface is friendlier than a terminal, but the system underneath behaves like a text file. That distinction is invisible until something goes wrong, and then it is the only thing that matters.
- Portainer-style: UI owns the state. Faster setup, polished features, lock-in risk.
- File-style: Compose files on disk are the source. Slower setup, full portability.
- Hybrid: Portainer supports both modes if you point it at a directory and let it watch.
Who is going to need to debug this at 2 AM
The second question is about who else touches this thing. A homelab run by one technical owner is a different operating environment than a stack that your partner, roommate, or a non-technical family member needs to manage. Most dashboards assume the single-operator case and put every advanced feature behind that assumption. Multi-user access, role-based permissions, audit logs, and remote agent control all exist in mature enterprise tools. They do not exist in the homelab-tier dashboard, and that gap is intentional.
If you run a Plex server that only you restart, any file-on-disk tool works. If your family can trigger a “click the button to fix Netflix” workflow, you need either a tool with a guest mode (Portainer’s read-only role, Dockge’s lack of one) or a documented runbook that tells them exactly which Compose file to copy and which Docker Compose command to run. Most homelab guides skip this question because the answer in their case is “no one else touches it.”
The honest split:
- Single owner who knows Compose: any file-on-disk tool. Saves you a layer of indirection.
- One technical owner plus occasional family help: file-on-disk tool plus a written runbook, or Portainer with role accounts.
- Multiple technical users or small business: Portainer CE or a paid tier, with named accounts and permissions.
- Shared family without anyone willing to learn Compose: Portainer CE with the app templates, even with the lock-in. The accessibility win is worth it.
How much does lock-in cost you specifically
Lock-in costs different things to different homelabs. If your entire server fits in a single Compose file you have memorized, lock-in is cheap. If you have fifteen stacks with custom networks, persistent volume mounts, and a dozen env files you tuned over time, lock-in is the kind of thing you only realize you cannot afford when you are trying to leave.
The math is rough but it works. Count the number of Compose files you actively maintain. Count the number of networks you have defined. Count the persistent volumes that hold actual data versus the ones that hold temporary state. Add up the time you would spend reconstructing each one if you had to do it from scratch today. If that total is under an hour, lock-in is a manageable tax. If it is more than a week, lock-in is a real risk and you want a tool whose source of truth is files you can read with cat.
Portainer is not the only tool with this trade-off, but it is the most visible because it is the largest. Cosmos stores stacks in a SQLite database. Some older dashboards used Docker Compose labels directly on the containers, which is even worse because the labels move with the container and you cannot edit them without recreating it. The file-on-disk pattern is the only one that makes lock-in a non-issue, because the file is yours regardless of which dashboard you point at it.
What happens when the developer disappears
This is the question nobody likes to ask because the honest answer is uncomfortable. Every homelab-tier tool has one or two active developers. If those one or two stop shipping, the project does not have a foundation waiting to catch it the way, say, a major Linux distribution does. That is not a reason to avoid smaller tools. Plenty of small projects ship for years with a single maintainer. It is a reason to check the maintenance signals before you commit your stack to them.
The honest maintenance questions:
- How many commits in the last six months? Anything above one commit a month on average is alive. Below that is a warning sign.
- How fast do issues get triaged? Open an issue or read a recent one. If the response time is weeks, the project is in maintenance mode, not active mode.
- Is there a paid tier behind the same developer? If yes, the project has a funding path. That is not a guarantee, but it is a signal.
- How much code is there to read? Smaller codebases are easier to audit and easier to fork if it comes to that. A 5,000-line codebase by one developer is more recoverable than a 500,000-line codebase by a foundation.
None of this tells you whether the project will exist in three years. Nothing does. The question is whether you can survive the project disappearing, not whether it will.
What is the actual cost of the move
The fifth question is the one most people do not want to do the math on. Migration cost is the silent tax on any tool switch, and it varies wildly depending on how your stack is set up. A homelab with two containers and no persistent data is a Saturday afternoon project. A homelab with fifteen stacks, a custom Docker network, persistent volumes that hold terabytes of media, and a Plex database that has been built up over years is a multi-week project with real risk of breaking things you do not remember you had.
The rough rule is that migration cost tracks data volume, not stack count. Two stacks with terabytes of data are more painful to move than ten stacks with no persistent state. The work is in moving the data, not the definitions. Most Compose files are short enough to copy and edit by hand. Volumes are usually just paths on disk. The tricky part is preserving the relationships between them, especially when one stack depends on another’s network or volume mount.
Tools that treat files as the source of truth make this cheaper because the files are already separated from the tool. Moving from Dockge to Cosmos is mostly moving folders. Moving from Portainer to anything else is extracting stacks from Portainer’s internal database, which is a process that varies depending on the Portainer version and which features you used. The clean way to think about migration cost is to assume you will move someday, and ask what that move looks like today.
Trade-offs
None of these questions have a single right answer for every homelab. The five-question framework is a way to make the trade-offs visible before you commit. A single-operator homelab with two stacks and a working setup does not need to think hard about lock-in or developer continuity. A multi-user setup with fifteen stacks and terabytes of media has very different math, and the cheap option is rarely the right one.
There is also the timing question. Switching tools when your current one works is a luxury. Switching tools when your current one breaks is a forced move and you do not get to choose the destination carefully. The honest path is to do the evaluation while nothing is on fire, so when the move becomes urgent you have a short list ready.
The real win is making the choice deliberate. A Docker dashboard that you picked because you read three threads about it and never thought about lock-in is fine until it is not. A Docker dashboard that you picked because you knew what it owned, who else touched it, how much it locked you in, and what would happen if the maintainer stopped shipping is a tool you can defend in a year. That difference is the only one that matters.
If you have been running the same UI for years without asking any of these questions, this is your reminder to ask them. Most homelabs will find that the current tool still passes, just with a clearer understanding of why. The ones that fail the audit usually fail loudly on the first question, and that is the answer you needed.