Our Docker for Beginners guide explains why almost every self-hosted app ships as a Docker container. The part that guide doesn't cover is that, day to day, most people don't want to type docker ps, docker logs, and docker compose up -d into a terminal every time they need to check on or update something. That's the exact gap Portainer fills: a web dashboard for everything you'd otherwise do with Docker commands.
What Portainer actually is
Portainer is itself a Docker container that talks to your Docker installation (via the Docker socket or API) and gives you a browser-based interface for everything Docker can do: starting and stopping containers, viewing live logs, checking CPU/memory usage per container, pulling new images, and — most usefully — deploying and editing multi-container setups defined in Docker Compose files, which Portainer calls stacks. If you've ever hesitated to try a self-hosted app because the install instructions were a wall of terminal commands, Portainer is usually the tool that removes that friction.
It comes in two editions: Portainer CE (Community Edition) is free and open source and covers everything a home server needs. Portainer BE (Business Edition) adds features aimed at teams managing many servers (RBAC, support contracts) that a homelab has no real use for. Everything in this guide is CE.
Installing Portainer
Portainer installs as a single Docker container. From a terminal on the machine running Docker (whether that's a Proxmox VM, an Ubuntu Server box, or a TrueNAS SCALE app), run:
docker volume create portainer_datadocker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest
That first command creates a persistent volume so Portainer's own settings and users survive container updates. The second starts Portainer itself, mounting the Docker socket so Portainer can actually see and control the other containers on the same host, and mapping port 9443 for the HTTPS web interface (and 8000, used for the optional Edge Agent feature most home users don't need). Once it's running, open https://<your-server-ip>:9443 in a browser.
docker rm -f portainer, then the run command again), since no real data is lost at that stage.
What you can actually do with it
- See everything running at a glance — every container, its status (running/stopped/unhealthy), CPU and memory usage, and which ports it's using, in one list instead of scattered terminal output.
- Start, stop, restart, and remove containers with a click, instead of remembering container names for
docker stop/docker rmcommands. - View and search live logs for any container — genuinely useful for troubleshooting a self-hosted app that isn't behaving, without SSHing in.
- Deploy stacks from Docker Compose files — paste or upload a docker-compose.yml (many self-hosted apps' install instructions are written exactly as one of these), and Portainer deploys the whole multi-container setup, then lets you edit and redeploy it from the same screen later.
- Update images — pull a newer version of an image and recreate the container with it, a common way self-hosted apps get updated without rebuilding your whole setup from scratch.
- Manage volumes and networks directly, useful when you need to see exactly where a container's data actually lives on disk.
Portainer vs just using Docker Compose from the terminal
Portainer doesn't replace Docker Compose — it's a friendlier front end for the same underlying concepts. Experienced self-hosters often still keep their compose files in a git repository and use the terminal for anything scripted or repeatable, then use Portainer mainly for quick day-to-day checks (is this container healthy, what does its log say, restart it) rather than as the only way they manage containers. For someone just starting out, though, Portainer is a reasonable place to do everything, including initial deployments, until the terminal feels less intimidating.
A note on security
Because Portainer has full control over Docker on the host it's connected to, treat access to it the same way you'd treat root access to that machine — use a strong, unique admin password, and don't expose the Portainer dashboard directly to the internet without something like a reverse proxy and authentication in front of it. If you eventually want remote access to your dashboards, our forthcoming guide on secure remote access (Tailscale vs VPN vs reverse proxy) covers the safer options.
Where Portainer fits in a typical setup
A common pattern for beginners following our Proxmox install guide: create one Ubuntu Server VM or LXC container dedicated to running Docker, install Portainer on it first, and then deploy everything else (Jellyfin, Immich, Pi-hole, Home Assistant) as stacks through Portainer's interface rather than juggling separate compose files by hand over SSH. It's a small extra step that pays off the first time you need to check why something crashed at 2am without wanting to remember exact container names.