Setup

Check requirements before installing

RuleFence refuses to run on an environment it cannot govern correctly. Confirming four things first turns a failed activation into a five-minute check.

Install & activate
3 min read

Platform

WordPress: 7.1 or later. Pre-release and source builds such as 7.1-RC1, 7.1-beta2 and 7.1-src are supported — the version check compares the release number, not the string.
PHP: 8.0 or later.
Database: MySQL or MariaDB with transaction support. The audit writer needs it, and a site where transactions cannot be established fails closed rather than recording partial decisions.
Abilities: At least one registered WordPress Ability, once you actually want to govern something. A site with an empty registry is a valid install with nothing yet to decide about.

Who needs to do the install

Activation, agent creation, and permission decisions all require an administrator. That is deliberate: the person who can widen an agent’s boundary should be the person who could already widen a WordPress user’s.

You will also need to be able to create a new WordPress user for the agent to connect as. Do not plan to connect an agent as your own administrator account — see Choose the WordPress user an agent connects as.

Hosting notes

Application Passwords must be enabled. Some hosts and security plugins disable them. They are the connection identity, so a site with them switched off cannot connect an agent.
REST API must be reachable. Agents authenticate over HTTP to the WordPress REST API. A plugin or firewall that blocks unauthenticated REST requests wholesale will also block the authentication step.
No outbound connectivity is required. Governance is local-first. Outbound access is only needed if you activate a paid licence.

Multisite

Single-site and multisite both work. New sites in a network get the schema installed automatically. Fleet governance across a network is an Agency-plan capability; the per-site control model is identical either way.

Install on staging first, if you have one

Not because the plugin is risky to install — it grants no permissions on activation — but because the useful part of learning is granting a first Ability and watching a real decision happen. Doing that on staging costs nothing if you get the boundary wrong on the first attempt.

Remember that a staging agent and a production agent are two separate identities with two separate credentials. See Keep staging and production agents separate.

Install & activate

Keep the boundary while you fix the problem.

A good fix restores intended behaviour without creating a second path around WordPress or the governed request lifecycle.