MontyGuard
Talk to us about a pilot
Menu

Maintenance for PHP and WordPress sites

Keep older PHP and WordPress sites patched, with every change tested first.

Many small business and agency websites run on PHP or WordPress that nobody is actively looking after. The risky jobs are often the ones care plans and auto-updaters skip: PHP upgrades that break the site, plugins abandoned with known security holes, and custom code from a developer long gone.

MontyGuard finds these problems, builds a fix and tests it on an isolated copy of your site. The fix goes live only with your approval. When MontyGuard deploys it, the live site is checked straight away, and if that check fails, the previous version goes back automatically. You get a plain-English report of what changed and how it was tested.

Talk to us about a pilot See how it works
  • Tested on a copy first
  • You decide what goes live
  • Rolled back if the live check fails
Example run Waiting for your approval

An update is ready and waiting for approval

PHP 7.4 to 8.3 upgrade, plus a security update for a contact form plugin

Checked on an isolated copy of the site

  • The site's PHP code passes a syntax check on PHP 8.3
  • Booking flow works
  • Contact form works
  • Known exploit request is blocked
  • No new errors in the PHP error log
  • Behaviour matches production
Diff policy: nothing blocked Previous release kept for rollback
An illustration of the evidence you see before a change goes live.

How it works

From finding to fix, with evidence at every step

Every change follows the same five steps, whether it is a routine plugin update or a difficult PHP upgrade.

  1. Step 1

    Monitor

    MontyGuard checks that each site is up and its key pages work. Where it can read the site's code, it also checks the PHP version against its end-of-life date and the plugins against vulnerability feeds. Anything risky becomes a finding you can see.

  2. Step 2

    Fix

    It builds the fix on a separate copy of the site. Vendor updates and known playbook recipes go first, then a sandboxed AI agent. If nothing passes, a person takes over.

  3. Step 3

    Verify

    The copy must pass your site's own business flows, the exploit check, a clean PHP error log and a behaviour comparison with the live site. Anything unproven stops here.

  4. Step 4

    Deploy

    Once approved, the new release goes live and the live site is checked straight away. If that check fails, the previous release is swapped back automatically.

  5. Step 5

    Report

    You get a plain-English report: what was found, what changed, how it was tested, and the exact code change.

You choose how hands-on it is

Each site runs in one of four modes, set per site. Every new site starts in Monitor only.

  • Monitor only Where every site starts

    Checks and alerts. Never builds or changes anything.

  • Propose

    Builds and verifies fixes but never deploys them. The report shows the proposed change.

  • Approve before deploy

    Verified fixes go live only after a named person approves them.

  • Automatic

    Routine vendor updates that pass every check go live on their own. Everything else, including every change written by the AI agent and anything the diff policy flags, still waits for a person. Switched on only with your written agreement, which we record before the switch.

The right fixer for each job

Fixes are tried in this order, and every one goes through the same checks.

  1. Playbook recipes

    Known, repeatable fixes, such as replacing functions that PHP 8 removed. The same problem always gets the same fix.

  2. Sandboxed AI agent

    For problems the playbook can't solve. It works on a scrubbed copy of the code in a locked-down container, and its changes wait for a person's approval.

  3. A person

    If no fix passes every check, the case goes to a person's queue. Nothing unverified is deployed.

A way back, built in

Whenever MontyGuard deploys a new release of your site itself, it keeps the previous one.

  • After every deploy, the live site is checked straight away.
  • If that check fails, the previous release is swapped back automatically, without waiting for anyone.
  • The rollback is recorded in the site's report and in the audit trail.

What we fix

The hard cases routine tools leave behind

Auto-updaters and care plans are good at installing a vendor's update when one exists. MontyGuard is built for the jobs that need real code changes and careful testing.

PHP upgrades that break sites

Old PHP versions stop getting security fixes, but moving up often breaks code that relies on functions PHP 8 removed, such as each() and create_function(). MontyGuard rewrites that code, updates WordPress core when the new PHP version needs it and the host allows it, and tests that the site still works. On hosts where PHP is changed in a control panel, such as GoDaddy, a person makes that switch with you, never automatically.

Abandoned plugins with known holes

When a plugin has a published vulnerability and no fix from its vendor, MontyGuard's AI agent writes a virtual patch that blocks the exploit. A second agent then attacks the patch with variations of the exploit. The patch has to block those too, while your business flows keep working, and a person approves it before it goes live.

Custom code from someone long gone

When a PHP upgrade breaks themes and plugins written for the site years ago, they get the same treatment: fixed on a copy, compared against how the live site behaves, and passed to a person whenever the evidence isn't clear.

Routine updates, verified the same way

Vendor plugin updates go through the same copy, checks, approval and rollback, so a routine update is tested against your booking, contact or checkout flow before visitors see it.

Safety

Careful by design, and honest about the limits

Changing a live website is a responsibility. These are the guardrails every change goes through.

  • Tested on an isolated copy

    Each fix runs on a separate copy of the site first. It must pass your business flows, such as booking, contact and checkout, the exploit check, a clean PHP error log and a behaviour comparison against production.

  • Read-only checks on your live site

    MontyGuard's checks on the live site are read-only page requests. It never submits forms there: form tests run on the copy.

  • Fixed rules screen every change

    A rule-based diff policy, not AI, checks every code change before it can ship. Backdoor-shaped code, such as eval, shell commands or unexpected outbound calls, is blocked and sent to a person.

  • Named approvals and rollback

    Changes wait for someone with the approver role, and each decision is recorded with who made it. When MontyGuard deploys, the previous release is kept and swapped back automatically if the live check fails.

  • An audit trail you can verify

    Security-relevant actions, from sign-ins to approvals, deploys and rollbacks, go into an append-only log. Each entry is chained to the one before it with a hash, so a later edit can be detected.

  • A sandboxed AI agent

    When the AI agent is used, it works in a locked-down container on a copy of the code with passwords and keys removed. The only place it can connect to is the AI provider's API.

What we don't claim

  • No tool can make a website unhackable. MontyGuard deals with known problems: outdated PHP, published plugin vulnerabilities and code that breaks on upgrade.
  • Support for WordPress hosts is new. MontyGuard reaches a site over SSH (GoDaddy Managed WordPress on Deluxe or higher, cPanel, or a server of your own) and replaces only the plugins and themes it fixes, keeping the previous copy to go back to. It has been tested against a GoDaddy-like test host but not yet on a real customer account, so every pilot starts read-only and we confirm each step on your account first. A site without SSH access can only be monitored: uptime and page checks.
  • Some jobs on managed hosts can only be done in the host's dashboard, such as switching the PHP version or restoring a host backup. MontyGuard gives a person the exact steps and checks the result; it never pretends it did them.
  • MontyGuard does not back up your site itself yet. In a pilot we rely on your host's backups, and we check that they can be restored before anything changes.
  • Our automatic checks look at pages and form results. Visual layout, features that depend on JavaScript and forms protected by one-time security tokens are not checked automatically yet.
  • Pilots are supervised by the MontyGuard team. A person on our team reviews each change before it is sent to you for approval.

For agencies

Your name on the work, your team in control

MontyGuard works behind your agency. Your clients see your name and your reports, and your team decides what ships.

  • Keep the client relationship

    Reports carry your agency's name. MontyGuard appears only as a small "Maintained by MontyGuard" credit.

  • One place for your whole fleet

    Every client site on one dashboard: PHP versions, open findings, changes waiting for approval and recent activity.

  • Roles for your team

    Viewer, approver, operator and owner. An account manager can approve changes without being able to change site settings.

  • You approve what ships

    Nothing goes live on a client site until someone on your team approves it. Only routine vendor updates can skip that step, and only on sites you switch to Automatic mode.

Your agency

Website maintenance report for your client

What we found

The contact form plugin had a published security hole, and the site's PHP version no longer gets security fixes.

What we did

Updated the plugin and moved the site to PHP 8.3, fixing old code that newer PHP no longer accepts.

How we checked

Booking and contact forms were tested on a copy before and after the change, and the live site was checked after the update.

Prepared for your client by your agency. Maintained by MontyGuard
An illustration of a client report: your agency's name at the top, and MontyGuard only as a small credit.

Pilots

We offer supervised pilots

Pilots are for a small number of web agencies and small businesses. Every pilot is supervised by the MontyGuard team, and nothing changes on your live site until you say so.

What a pilot looks like

  1. Read-only baseline

    We take stock of what runs on your site, agree which business flows matter, list current vulnerabilities and check that your existing backups can be restored. Nothing on the site changes.

  2. Monitor only

    At least two weeks of monitoring and alerts, with no changes to your site.

  3. Supervised fixes

    Each fix is verified on a copy, reviewed by our team and deployed only with your approval, in a change window you agree.

  4. Regular reports

    A monthly report against success criteria we agree at the start, and a joint decision at the end on whether to continue.

Talk to us about a pilot

Tell us how many sites you look after and which jobs keep getting put off. We will explain how a pilot would work for you.

Email us about a pilot

or write to hello@montyguard.example