Network ingress and egress, in plain terms
Two words come up a lot once you start running your own services: ingress and egress. They simply name the direction traffic is moving relative to your machine.
Ingress is traffic arriving in to your box, a browser loading your web panel, or a device connecting to reach a service you host.
Egress is traffic leaving your box for somewhere else, downloading an image, a container fetching from an API, or routing traffic out through a VPN.
The terms describe the direction traffic is flowing relative to your box, not who is in charge of it, and any single connection carries traffic both ways. Getting the direction straight saves a lot of confusion once VPNs enter the picture, because a VPN can serve either direction, and the two set-ups are not interchangeable.
Where this matters on your seedbox
When you want to reach a service running on your seedbox from your laptop, that is an ingress problem: you need a way in. When you want a program on the seedbox to send its traffic out through somewhere else, that is an egress problem: you need a way out. WireGuard can be part of either picture, but the two are set up differently and PMSS only ships a ready-made tool for one of them.
WireGuard for ingress: connecting your devices to the seedbox
Your account already includes a ready-made WireGuard profile for the ingress case. It creates a private tunnel so your own devices can connect in to the seedbox securely, for example to reach a service you run on the seedbox without exposing it to the public internet.
Import the provided profile into the WireGuard app on your device and connect. That is the inbound tunnel: it brings you to the box. It does not route your box's outbound traffic anywhere, that is the other direction, and a common point of confusion. One more thing worth knowing: by default the profile also sends your device's own internet traffic out through the seedbox, so websites see the seedbox's address instead of your home connection while the tunnel is on.
One detail that trips people up: a service only reaches you through this tunnel if it is bound to all interfaces on the seedbox, or to the tunnel's own address. A service you have bound to localhost (127.0.0.1) is not reachable this way. Loopback traffic never leaves the machine it runs on, tunnel or not, so binding something to 127.0.0.1 only makes it reachable from other processes on that same machine, never from your WireGuard-connected device. Also keep in mind that other accounts on the same seedbox share this same tunnel network, so put authentication in front of anything you expose this way regardless.
WireGuard for egress: routing a container's traffic out through your own VPN
If what you actually want is for a program's traffic to leave the seedbox through your own VPN provider, that is the egress case, and on PMSS it is a self-managed setup rather than a ready-made feature. Your account includes rootless Docker, so you can pull a WireGuard client image, point it at your own VPN provider's connection details, and let other containers share its network so their outbound traffic exits through it.
Run docker-help in your shell for general container tooling and guidance. There is a WireGuard-container helper listed there, but it sets up a separate, self-managed WireGuard server for your own extra devices to connect into, the same ingress case as above, just a second isolated tunnel under your own control. It is not a VPN-provider client and does not route other containers' traffic out through a third-party VPN. Building that specific egress setup means running and configuring a client-mode VPN container yourself.
Quick reference
Reaching your box from outside (ingress) → the built-in WireGuard profile, imported on your device.
Sending a program's traffic out through your own VPN provider (egress) → a self-managed VPN client container you build yourself; not the WireGuard-container helper from docker-help, which sets up a server for your own devices instead.
They point in opposite directions, so if one is not doing what you expect, it is usually because the other one is the tool you actually wanted. If a fresh container does not come up on the first try, mention it on a ticket.
