Homelab Journey Part 9: Managing Everything with Portainer

Portainer is useful because it gives me a window into the Swarm.

It is not the source of truth. That distinction matters.

The source of truth is the repository: stack files, Ansible roles, variables, and the notes that explain how the lab is meant to work. If I change everything by clicking around in a UI, the next deploy becomes a surprise.

So I use Portainer carefully. It helps me see what is happening. It does not replace the deployment process.

Why I keep it

A Docker Swarm can be managed from the command line just fine.

Most of the time, that is enough. But when I want a quick answer, Portainer is faster. Which services are running? Which node is hosting this task? Did a container restart? What does the log say? Is the image the one I expected?

Those are small questions, but they come up often.

Portainer gives me a quick view without SSHing into several Pis or remembering the exact command while I am half-focused on the real problem.

That is a good use of a UI.

What I do not use it for

I try not to use Portainer for permanent changes.

It is tempting. The button is right there. Change an environment variable, restart a service, tweak a setting, and everything looks fixed. The problem comes later when the repository still says the old thing and a redeploy puts it back.

That is how configuration drift starts.

If a change matters, it goes into the repo. Portainer can help confirm the current state, but it should not become a secret second configuration system.

Day-to-day use

The normal uses are simple:

• check service health
• inspect logs
• see which node a task landed on
• confirm networks and published ports
• restart something small when I already understand why
• spot containers that are crash-looping

That covers most of what I need.

The value is speed. Portainer shortens the feedback loop when I am diagnosing a service. It does not make the diagnosis for me, but it puts the evidence in one place.

It helps after a gap

Homelab work is not continuous.

I might go weeks without touching the cluster. Then something needs an update, or a service stops behaving, and I have to reload the whole mental model.

Portainer helps with that. It gives me a quick map of the running system before I dive into files and playbooks. That is especially useful on a multi-node setup where the service I care about might not be running where I expected.

This is one of the underrated parts of a homelab tool: helping you remember what you built.

The risk of clickops

The risk is clickops.

Clickops feels productive because it fixes the immediate thing. It is also hard to review, hard to repeat, and easy to forget. In a small homelab, that may not sound serious, but it still causes pain. The next rebuild or migration exposes every undocumented change.

So I treat Portainer like a control panel, not a development environment.

Temporary change for diagnosis? Fine. Permanent change? Put it in Git.

Why not just use commands

Commands are still the backbone.

I use Docker, Ansible, logs, and config files all the time. Portainer does not remove that. It just gives me a better first glance and a convenient way to inspect the Swarm when I do not need the full ceremony.

There is no prize for making every small task more manual than it needs to be.

The important thing is knowing which tool owns which job.

The takeaway

Portainer works well in my homelab because I keep it in its lane.

It gives visibility. It helps with quick checks. It makes the Swarm easier to understand after a break. It gives me a practical UI without turning the UI into the deployment process.

That is the balance I want. Helpful, but not authoritative.