.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
The command is:
docker restart portainerThat's it for the common case, on a Raspberry Pi, a VPS or anything else running Docker, because Portainer is just a container and containers restart like containers. You can stop reading if the UI is back at :9443. You're welcome - because I don't like to make you read an entire article for a simple answer.
The rest of this page is the variants (compose installs, unknown container names, restart-at-boot) and the three situations where people search for this command in the first place, each with its own follow-up.
Restart variants by install type
The plain command assumes the container is named portainer, which the official install does. Name unknown or nonstandard? Find it, then restart by whatever it's called:
docker ps -a --format '{{.Names}}\t{{.Image}}' | grep -i portainer
docker restart YOUR_NAMECompose installs restart from the directory holding the compose file (or with -f pointing at it):
docker compose restart portainerAnd the harder reset, for when a plain restart didn't clear whatever state you're fighting: recreate instead of restart. docker stop portainer && docker rm portainer, then re-run the original run command from the install guide; the data volume survives and you get a genuinely fresh process. On compose that's docker compose up -d --force-recreate portainer, one line doing the same surgery.
Restarting Portainer on a Raspberry Pi
Nothing about the commands changes on a Pi (the search phrase suggests otherwise, so let's be explicit: same Docker, same syntax, ARM images handle themselves). What is Pi-specific is the aftermath: SD-card storage makes Portainer's startup noticeably slower than on a VPS, so give it thirty seconds before declaring the restart failed, and docker logs -f portainer shows it working through startup if you're the impatient type. I am, it's fine.
Pi people also hit reboots more often (power blips, the SD card lottery), which makes the next section theirs especially.
Restart Portainer at boot automatically
Portainer should come back on its own after every reboot, and the restart policy in the run command is what promises that. Check yours:
docker inspect -f '{{.HostConfig.RestartPolicy.Name}}' portaineralways is the answer you want. Anything else (empty, no) means someone's install command dropped the flag, fixable in place without recreating anything:
docker update --restart=always portainerOne layer beneath that, Docker itself has to start at boot for the policy to matter: systemctl is-enabled docker should say enabled, and sudo systemctl enable docker fixes it where it doesn't. Those two settings together are the difference between a self-healing setup and a Pi in a cupboard nobody can log into after a power cut.
The three reasons people restart Portainer, and what comes after
From forum archaeology and my own history, this command gets reached for in three situations, and the restart is only step one in two of them.
The security timeout on a fresh install. New Portainer, nobody created the admin account within the five-minute window, and the UI now shows "your Portainer instance has timed out for security purposes". The restart re-arms the timer, per Portainer's own FAQ; go create the account promptly this time. This is the number one source of first-day restarts and it's working as designed, oddly comforting once you know.
The UI stopped responding. A restart usually clears it, and if it recurs, the restart is treating a symptom: check the machine's memory and disk (free -h, df -h), since a starving host strangles the panel first and your containers next. Chronic unresponsiveness on an overloaded box is a sizing conversation, the kind the Portainer VPS tiers exist to end.
Something's wrong after a change. An update, an environment edit, a migration. Restart, sure, and read docker logs --tail 50 portainer before assuming the restart fixed it; errors that survive a restart are configuration, and the message names which kind. The one that mentions environments has its own page in our local environment error fix.
Restarting Portainer is wonderfully consequence-free, by the way, and worth internalizing: your containers belong to Docker and keep running through it, sessions reconnect, nothing about your stacks changes. It's the rare admin action with no downside, wich is exactly why it makes such a good first move.
