How to Manage Docker Containers from an iPhone
Something is down and you are not at a desk. The fix is usually small: restart a container, read the last fifty log lines, clear a full disk. But doing it by typing `docker logs --tail 50 --timestamps` on a touchscreen, with a container name you half remember, is miserable enough that people put it off until they get home. This covers doing it properly from a phone, including the part most guides skip: what to check before restarting something.
Written by the GateShell team at Hefty Innovations
Step by step
- 1
Connect over SSH, and do not expose the Docker socket
Before anything else, a warning worth taking seriously. Guides sometimes suggest exposing the Docker daemon on TCP 2375 so remote tools can reach it. Do not. Access to the Docker socket is effectively root on the host, and an exposed daemon is one of the more reliably exploited misconfigurations on the internet. SSH in and run docker there, as you would locally. GateShell's dashboards work this way, over your existing authenticated SSH session, with no daemon port open.
- 2
Open the Docker dashboard
Connect to the server and open the Overview tab. Docker is detected automatically if it is present, alongside the other services on the host. The dashboard lists containers with their state, so you can see what is running and what has exited without recalling the exact `docker ps -a --format` invocation.
- 3
Read the logs before you restart anything
The instinct is to restart and see if it helps. Resist it for thirty seconds: restarting destroys the evidence of why the thing failed, and if it recurs you have learned nothing. Open the container's logs first. An OOM kill, a failed migration, and a bad config all look identical from outside and have very different fixes. Read, then act.
- 4
Restart or stop from the dashboard
Container actions are available directly. Because GateShell detects whether a service runs natively or in a container, mutating actions target the right thing. A `systemctl restart` silently does nothing for a containerised service, which looks exactly like a working button. Anything mutating goes through the guardrail first, so a destructive command shows you what it will do before it runs.
- 5
Check disk before assuming the app is at fault
A large share of production incidents on small servers are a full disk wearing a different mask. Docker accumulates images, stopped containers, build cache, and log files, and the symptoms, a container that will not start or a database refusing writes, rarely mention disk at all. The Overview shows disk usage at a glance, and the cleanup tooling identifies what is safe to reclaim.
- 6
Set up alerts so next time it finds you
The best version of this workflow is not being faster to react but not having to. Install the optional agent on the server and it watches locally, pushing a notification when a service drops, a disk crosses its threshold, or a cron job fails. That turns the phone from a tool you reach for after noticing into the thing that tells you.
Frequently asked questions
Do I need to expose the Docker API to manage containers remotely?+
No, and you should not. Exposing the Docker daemon on a TCP port hands effective root on the host to anyone who reaches it, and unsecured daemons are scanned for constantly. Running docker commands over an authenticated SSH session gets you the same control with none of that exposure. GateShell never asks you to open a daemon port.
Can I manage Docker Compose stacks too?+
Yes. Compose projects appear alongside individual containers, and there is a guarded workflow for reviewed image updates with health verification and explicit rollback, which is the operation you least want to perform blind from a phone.
What if my database runs in a container rather than natively?+
Detection handles both. The dashboards check for a native install and fall back to finding the service inside a container, then target actions accordingly. This matters more than it sounds: restarting a containerised service with systemctl exits successfully and does nothing at all.
Will I see the logs of a container that has already exited?+
Yes. Logs persist after a container stops, which is exactly when you need them. This is why reading before restarting is worth the thirty seconds: the logs survive, but the running state that produced them does not.
Is this a replacement for Portainer or Docker Desktop?+
Not really, and it is not trying to be. Those are full management UIs for sustained work at a desk. This is for the smaller, more common case: something needs attention, you are not at your desk, and the fix is one action away if you can see what is happening.
Try it in GateShell
GateShell is a zero-backend SSH client for iPhone, iPad, and Mac, with no vendor cloud, no accounts and no telemetry. Everything above works out of the box.
Guide reflects GateShell's shipped features as of September 2026. Steps assume basic familiarity with SSH and the command line; server-side commands may vary by distribution. All product names, logos, and brands are property of their respective owners.