All posts

blog

How to manage Docker containers on a remote VPS

Published

Every way of managing containers on a rented server answers one question first: where does the thing you click or type into actually run? Get that answer right and the choice of tool mostly makes itself.

The question underneath the tool question

Search results for this topic are mostly lists of tools. The more useful split is by where the control plane lives — the part that holds the credentials, receives your commands and talks to the Docker daemon.

There are four places it can live: in your terminal, on the network as an exposed daemon port, in a web panel on the server, or in a desktop app on your own computer. Each one moves cost and risk to a different place.

Option 1: a terminal over SSH

The baseline. You already have SSH access to the server, and every Docker operation is one command away. It costs nothing, needs nothing new on the server and works on any Linux machine you can log into.

Docker contexts make it a little nicer: point your local docker command at the remote daemon over SSH, and docker ps on your laptop lists the containers on the server.

Two equivalent ways to see what is running

# log in, then run the command there
ssh deploy@203.0.113.10
docker ps

# or stay in your local shell and send commands over SSH
docker context create my-vps --docker "host=ssh://deploy@203.0.113.10"
docker --context my-vps ps
docker --context my-vps logs -f --tail 100 web

What it costs is recall, not money: which directory the stack lives in, which flags the container was started with, and which server this terminal is connected to right now.

Option 2: expose the Docker daemon

You can make the daemon listen on a TCP port and point clients at it. Older tutorials still suggest it, and it is the option to skip: daemon access is root on the host, port 2375 has no authentication at all, and the TLS variant on 2376 makes you the operator of a certificate authority.

The full argument has its own post, so it is not repeated here.

Option 3: a web panel on the server

Portainer, Coolify, Dokploy and similar tools run as containers on the server itself and serve a web interface. They are capable and mostly free, and their advantages are real: you can open them from any browser, several people can share one, and whatever they automate keeps running while your laptop is closed.

The cost is that the panel is a second system. It mounts the Docker socket, so it is root-equivalent; it has a login page that must be reachable from wherever you are; it has its own database, its own updates and its own security advisories to follow. A panel that manages several servers also holds a credential for each of them.

Option 4: a desktop client over SSH

A desktop app can do what you would do in the terminal — open an SSH connection from your computer and run Docker commands on the server — and show the result in a window instead of as text.

Nothing new listens on the server, and the SSH keys stay on the machine you use. The trade-off mirrors option 3: it works on the computers where it is installed, it is one person’s tool rather than a shared one, and nothing it does keeps running once you close it — unless the tool installs something on the server for that, which is worth asking about.

Choosing by situation

  1. 01One server, just you, a few deploys a month: the terminal is genuinely enough. Write down the commands you repeat.
  2. 02Several people need access, or you want to check on things from a phone: a server-side panel is built for that, and its costs are the price of shared access.
  3. 03You want to push to Git and have the server build and deploy on its own, with preview environments: that is home ground for a PaaS-style panel.
  4. 04You work alone or in a small team, want a visual view of several servers, and do not want another internet-facing service: a desktop client fits.

Where MihraOps fits

MihraOps is option 4. It opens an ordinary SSH connection from your computer, runs Docker and Compose commands on the server, and keeps your server credentials in your operating system’s encrypted storage.

It is not the answer to the other three situations. There is no web login to share with a teammate and no dashboard to check from a phone. The one component it can put on a server is an optional Agent for deploy webhooks and alerts, which you install on purpose and can remove. If you are weighing it against a specific panel, the comparison pages go product by product.

Read next