One list of addresses, kept in your Tulapp account, that your sites pull down and honour — so you can restore your own access from anywhere, even from a site you're currently locked out of.
Every site has a local allowlist, edited in the plugin's own Access & Isolation tab, and a Cloud allowlist, edited in your Tulapp panel. The plugin uses the union of both — the Cloud list is additive, never a replacement.
That matters in practice: adding an address in the panel can never remove one you set locally, and a site with no Tulapp connection keeps working exactly as it did before.
In the panel, go to Static Shield Sites, find your site, and expand Trusted IPs under Access. You can either press + Allow my current IP — which uses the address the panel actually sees you connecting from, not one you type — or add an entry manually with a label.
The same list is visible read-only inside WordPress, as the Cloud-Synced Trusted IPs card on the Access & Isolation tab, along with when the site last synced. You cannot edit it there — the panel is the source of truth, which is what makes it useful when the site is unreachable.
Accepted formats:
Tulapp
203.0.113.42203.0.113.0/24
Ranges are deliberately bounded. IPv4 must be /24 or narrower and IPv6 must be
/64 or narrower — a /24 is already 256 addresses, which covers an
office or an ISP's dynamic range. Anything broader is refused, because a wider range is
almost always either a typo or an attempt to defeat the point of a scoped allowlist.
Write the network address, not your own address, with a prefix.
203.0.113.42/24 is rejected — the host bits have to be zero, so the range
containing that address is written 203.0.113.0/24. This trips people up
because the panel reports every rejection with the same generic "that doesn't look like a
valid IP or CIDR" message, whatever the actual reason was.
A label is required on every entry — it is what makes the list readable a year later.
Sites pull; Tulapp never pushes. A WP-Cron job checks in with Tulapp Cloud roughly every 15 minutes and caches whatever it gets locally, so the list keeps working even when Tulapp is unreachable.
Two things to know before you rely on it in an emergency. It is not instant — budget up to about 15 minutes. And WP-Cron only fires when the site receives a request, so a site with no traffic at all may not sync on its own. If you have just locked yourself out, use the immediate sync below rather than waiting.
The panel shows a Sync now on this site link next to your Trusted IPs. It opens a route on your own site:
https://your-site.example/wp-json/tulapp-shield/v1/allowlist/sync
This works even when you cannot reach wp-admin, which is the whole reason it exists. It lives under the Shield Bridge API namespace, and every protection mode — including Zero-WordPress Mode and Vault Mode — deliberately keeps that namespace reachable so there is always a way back in. Opening the link tells the site to fetch the current list from Tulapp immediately instead of waiting for cron.
wp-login.php and wp-admin to allowlisted addresses.Vault Mode ignores this list entirely, on purpose. Vault Mode's promise is that nobody has standing access — including you. A trusted IP does not open a sealed vault; only a short-lived grant from Tulapp Cloud does. See Recovering access.
If the Admin Access Gateway is switched on but the effective allowlist is empty, it does not block anyone. This is deliberate: it means you cannot lock yourself out simply by enabling the feature before adding your address.
The flip side is that an enabled gateway with an empty list is not protecting anything. If you expect it to be enforcing and it isn't, check that the list actually has entries.
A dynamic address that changes while a protection mode is active is the most common way people lose access. In order of preference:
Next: Recovering access with SSH or WP-CLI · Webserver configuration