01 - Nov - 2026

I replaced Portainer, Watch Tower, and Uptime Kuma with a container that does all three

There’s something slightly ridiculous about running several containers just to look after your other containers. Before you know it, you’ve got one interface for deployment, another handles updates, and a third tells you when something stops working. Each tool might have a job, but managing them all can become a hassle.

But you don’t need all three, because there’s a single Docker container that can do it all: Dockhand. It combines container management, scheduled image updates, resource monitoring, and notifications. The container can consolidate three workflows into one, albeit with a small catch.

One container to babysit the other containers

SQLite by default, a Docker socket you shouldn’t be casual about

Dockhand‘s default installation is quite simple. Its Docker configuration uses the fnsys/dockhand:latest image, publishes the interface on port 3000, mounts the Docker socket, and stores persistent data in a volume at /app/data. SQLite is the default database, so there’s no separate database container to maintain either. PostgreSQL is optional here too.

While this makes the basic deployment rather approachable for anyone, I wouldn’t treat it like a normal dashboard. Access to the Docker socket gives Dockhand a lot of control over the host’s containers. The manual also says authentication starts disabled, so enabling it becomes one of the first configuration steps. Dockhand recommends keeping the interface on a private network or behind a VPN rather than exposing it directly to the internet.

Dockhand does the daily Docker chores without the tab-juggling

Logs, a terminal, and Compose in one place

Dockhand running in web browser showing logs.
Photo taken by Yadullah Abidi | No attribution required.

Dockhand makes for quite the interface to handle routine container administration tasks. It supports starting, stopping, restarting, and removing containers, along with managing images, networks, and volumes. An interactive browser terminal, file browser, and streaming logs put common troubleshooting tools beside the controls you need to act on a problem. This gives you a major advantage when investigating troublesome services. You don’t have to constantly jump between a dashboard, an SSH session, and a separate log viewer.

Compose support makes the interface useful for more than just individual containers too. Dockhand includes a visual Compose editor, stack deployments, templates, and Git-backed deployments with webhook triggers and scheduled synchronization. It also advertises adoption of stacks from other managers. That said, I’d still back up Compose files and check storage paths before changing any applications that manage them.

Scheduled updates, minus the “what just changed?” panic

Safe-pull checks the image before it touches your running container

Dockhand containers with pending updates.
Photo taken by Yadullah Abidi | No attribution required.

Automatic updates are where Dockhand starts doing more than a conventional management dashboard. Scheduled checks can identify newer images and either notify you or deploy updates automatically. Those settings can apply across entire environments, while individual containers can have their own automatic-update schedules. You have the option of daily, weekly, or custom cron schedules to make room for all sorts of maintenance routines.

That separation is actually quite helpful. Just because one of my containers discovers an update, that doesn’t mean I want it automatically installed. A disposable or experimental utility and a database-backed application need different levels of caution when updating.

You also get safe-pull protection. Dockhand says it pulls a candidate image to a temporary tag and scans it before replacing the running container. If there are vulnerabilities that exceed the configured criteria, Dockhand deletes the temporary image and leaves the existing container untouched. That’s a more useful security check than you might realize.

Keeping update controls beside container logs and management tools makes the workflow more coherent and simple. You can find an available image, decide when to install it, and investigate the result, all from the same interface.

It watches your containers, not your actual services

A container can be running and still be useless

Dockhand main environment screen.
Photo taken by Yadullah Abidi | No attribution required.

Dockhand provides live CPU and memory information, container status, activity logs, and notifications for events like crashes and updates. Notification options include email, webhooks, and messaging services like Telegram, Discord, ntfy, and Gotify through Apprise. For basic container visibility, you’ve got more options than you need.

That said, a running container and an available service are two separate events. A container can continue running without any issues but the resulting service might have runtime errors. Docker health information also depends on checks configured for that specific container. Uptime Kuma’s URL and service monitoring addresses a problem Dockhand completely ignores.

In this case, the success of the replacement depends on what you actually monitor. If Uptime Kuma only watches Docker container status, Dockhand covers that requirement. But if you need to check websites, ports, or application responses, Uptime Kuma is the better alternative.

Fewer containers, same amount of babysitting

Free, telemetry-free, and not quite open source

Dockhand’s strongest argument is bringing closely related jobs together without requiring cloud infrastructure or telemetry. Its free edition covers container management, Git integration, vulnerability scanning, and authentication — more than enough features for home lab use. However, it does use the Business Source License 1.1, not an unrestricted open-source license. The site also lists commercial licensing separately.

So judge the switch by responsibilities covered, not by how many containers you can replace. Dockhand can centralize management, updates, and basic container monitoring. Independent uptime checks, however, are a different beast entirely, and decide whether someone can actually use said service, not whether the Docker container running it is still alive.

Leave a Reply

Your email address will not be published. Required fields are marked *