.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Quick answer first, because most people arrive mid-task: the Portainer default port is 9443, HTTPS, for the web UI. Port 9000 is the old HTTP interface and modern installs don't publish it. Port 8000 belongs to Edge agents and stays closed unless you use them. That's the whole map; the rest of this page is what each one means in practice, when 9000 still earns a place and which ports face the internet on a real server.
What each Portainer port does
A standard install publishes two ports and people remember a third from older tutorials:
- 9443/TCP, the UI over HTTPS with a self-signed certificate out of the box. Every current guide, including our Portainer install walkthrough, points you here.
- 8000/TCP, a tunnel server for Edge agents (Portainer's mechanism for managing remote machines behind NAT). No Edge agents, no reason for this port to exist publicly; it rides along in the official run command and can be dropped from it entirely.
- 9000/TCP, the legacy HTTP UI. Portainer served plain HTTP here for years, which is why the internet's muscle memory says 9000. It still works if you publish it (
-p 9000:9000), and unencrypted admin panels stopped being acceptable a while ago, so treat it as a compatibility escape hatch rather than an option.
The one case where I still publish 9000 on purpose: behind a reverse proxy on the same machine, where the proxy terminates real HTTPS and talks plain HTTP to Portainer over localhost. Proxying to 9443's self-signed HTTPS works too but needs the proxy told to skip upstream verification, and plain-HTTP-on-localhost is the simpler contract. Either way the proxy owns the public side; the pattern is the same one our Nginx reverse proxy guide builds.
Firewall rules for each kind of setup
Three scenarios cover nearly everyone. On a home LAN box, allow 9443 from your local subnet and open nothing in the router; Portainer has no business being internet-reachable from a household setup. On a VPS you admin alone, my preferred arrangement is 9443 closed in the cloud firewall and reached through an SSH tunnel (ssh -L 9443:localhost:9443 user@server), which costs one command per session and removes the login page from the internet entirely; a control panel that can start privileged containers is the most valuable target on the machine. On a VPS a small team shares, the tunnel gets old, so front it with the reverse proxy on 443, restrict by IP where the team's addresses allow it and keep 9443 and 8000 off the public interface. The panel firewall on our Portainer VPS plans handles the cloud-side half of those rules.
Ubuntu-side, the strict versions look like:
sudo ufw allow from 192.168.1.0/24 to any port 9443 proto tcp # LAN case
sudo ufw deny 9443/tcp # VPS + tunnel caseChanging the Portainer port
Port collisions happen (another panel, another app claiming 9443). The published port is yours to move in the run command or compose file; only the left side changes:
ports:
- "9543:9443"Portainer now answers on 9543 while the container still listens internally on 9443. Update bookmarks and any proxy upstreams, and note the same left-side-only rule applies if you ever remap 8000. There's no in-app setting for this; the mapping is Docker's job, one of the small ways Portainer stays a well-behaved container like any other.
Check which ports are live
When the UI won't load and you suspect ports, two commands settle it from the server:
docker port portainer
ss -tlnp | grep -E '9443|9000|8000'The first prints the container's actual mappings (the truth beats whatever the compose file was supposed to say), the second shows what the host is listening on. Mappings correct but no answer from outside means firewall or security group; no mappings at all means the container isn't running, which is a restart-from-terminal situation rather than a networking one. Two commands, ninety seconds, and the port question stops being a mystery, which is about all a ports page can promise.
