Every staging gets its own container pair on its own network, with outbound traffic default-denied and email blocked outright. A plugin you are testing cannot mail your customers, cannot reach your payment gateway, and cannot see another tenant on the platform.
The real hazard of restoring a live site is not that a plugin turns hostile. It is that the copy behaves exactly like the original: order hooks fire, password resets go out, integrations sync. The container is built so none of that reaches the outside world — outbound traffic is denied unless the destination is on an allow-list you control, and email is refused at two independent layers no setting can lift.
Each staging brings up its own bridge network with its own subnet, and it is torn down with the stack. The container runtime drops traffic between separate bridges, so one staging cannot reach another customer's web or database container — by name or by raw address. Only the reverse proxy is joined to each network.
Outbound traffic is refused unless the destination is on the allow-list. WordPress.org and the update and licensing endpoints of the common commercial plugins are there so your updates work. Payment gateways and webhook relays are not — we show you what your own plugins ask for and you decide, per site.
WordPress mail is disabled, PHP's mail path writes to a log you can read instead of sending, and every SMTP, POP3 and IMAP port is closed — inside the container and again on the host, so a plugin opening its own socket gets nowhere. This one has no override, because the people it protects are your customers.
A policy that has never been attacked is a guess. Each boundary below is exercised against a container that has had its own protections removed, so what is measured is the layer underneath — the one a compromised plugin cannot switch off.
Worst case it burns down a container we were going to delete in 72 hours.