Recovering access with SSH or WP-CLI — Static Shield Docs

First: your public site is fine

Being locked out of wp-admin does not take your site down. Visitors are served the static release by your webserver without WordPress running at all — that is the entire point of the product. You are recovering your own admin access, not restoring an outage. Work calmly.

Why WP-CLI always works

All three protections check for WP-CLI first and return immediately when they find it. That check is the very first line of each guard, before any allowlist or grant is consulted, so it cannot be affected by how you have configured them:

// the first thing every guard does
if ( defined( 'WP_CLI' ) && WP_CLI ) {
    return;
}

So the recovery question is never "will the CLI let me in" — it is only "which setting do I need to change". The sections below give the exact command for each.

The test is defined( 'WP_CLI' ) && WP_CLI, so it needs a real WP-CLI run. A hand-written PHP script that loads wp-load.php without defining WP_CLI is not exempt and will be blocked exactly like a browser request. Use wp, not php -r.

Locked out by the Admin Access Gateway

Symptom: wp-login.php and wp-admin return 403 from your address.

Add your current address to the local allowlist:

wp option patch insert tulapp_static_shield_admin_gateway_allowlist 0 "203.0.113.42"

Or switch the gateway off entirely:

wp option update tulapp_static_shield_admin_gateway_enabled ""

You can also fix this without shell access — add the address in the Tulapp panel and open the sync link. See Trusted IPs.

Locked out by Zero-WordPress Mode

Symptom: every dynamic route is denied, not just wp-admin.

wp option update tulapp_static_shield_zero_wp_enabled ""

Adding your address to the allowlist above works too — Zero-WordPress Mode honours the same list — and is preferable, since it restores your access without turning the protection off for everyone.

Emergency Lockdown is engaged

Emergency Lockdown isolates WordPress completely, ignoring the allowlist — even your own admin IP loses access until it is lifted. To lift it:

wp option delete tulapp_static_shield_zero_wp_emergency_lockdown

Vault Mode is sealed

Vault Mode is the one mode where an allowlist will not help you: it ignores standing access by design, so there is nothing to add yourself to. There are two ways back.

Without shell access — wake it from the panel

This is the intended path, and the reason the wake button lives in Tulapp rather than in wp-admin: wp-admin is exactly what is unreachable while the vault is sealed. In your panel, expand Vault Mode on the site's card and press Wake WordPress. It opens a short-lived, signed grant for your current IP (or a CIDR range you type). Sleep Now reseals it immediately.

Cloud Wake needs PHP's sodium extension on your server. Grants are Ed25519-signed, and without ext-sodium the site cannot verify one — every wake attempt returns invalid or unverifiable grant, no matter how many times you press the button. ext-sodium is bundled with PHP 7.2 and later, so this is rare, but on a build without it, SSH is your only route back. Check with php -m | grep sodium.

With shell access

The plugin ships two WP-CLI commands for Vault Mode:

# show the current state and any open grant
wp shield vault status

# remove any open grant and seal the vault
wp shield vault seal

Note there is deliberately no wake command. Tulapp's private signing key never leaves Tulapp's own servers, so a local CLI has no way to construct a valid grant — and does not need one, because WP-CLI already bypasses Vault enforcement entirely. If you have shell access, you already have full control regardless of grant state.

To turn Vault Mode off altogether:

wp option update tulapp_static_shield_vault_mode_enabled ""

If WP-CLI is not available

The settings above are ordinary WordPress options, so you can change them directly in the database. The relevant rows in wp_options (with your table prefix) are:

tulapp_static_shield_admin_gateway_enabled
tulapp_static_shield_admin_gateway_allowlist
tulapp_static_shield_zero_wp_enabled
tulapp_static_shield_zero_wp_emergency_lockdown
tulapp_static_shield_vault_mode_enabled
tulapp_static_shield_vault_access_grant
tulapp_static_shield_cloud_allowlist — the cached copy of your Tulapp Trusted IPs

-- turn a protection off (adjust the wp_ prefix)
UPDATE wp_options SET option_value = ''
 WHERE option_name = 'tulapp_static_shield_zero_wp_enabled';

The allowlist options hold serialized PHP arrays, not plain strings. Editing those two by hand in SQL is easy to get wrong — prefer wp option, and if you must use SQL, the safe move is to disable the protection rather than try to hand-edit its list.

Deactivating the plugin lifts every one of the protections above at once, since none of the guards run when the plugin is not loaded:

wp plugin deactivate tulapp-static-shield

Deactivating does not undo your webserver configuration. The # BEGIN Tulapp Static Shield block stays in .htaccess, and any nginx or Caddy rules you pasted stay in your server config — nothing removes them on deactivate or uninstall. Your public site therefore keeps being served from tulapp-static/, frozen at the last build. wp-admin still works, because the rules carve it out. To fully revert, remove that block yourself. See Webserver configuration.

Prevention

Add a CIDR range rather than a single address if your IP is dynamic.
Keep at least one address in the Tulapp panel — it is reachable when your site is not.
Confirm you still have SSH or WP-CLI before enabling Vault Mode.
Remember an enabled gateway with an empty list protects nothing — check it has entries.

Getting back in