Maintenance hosting where an update is provably safe to apply.
You sell a promise that nothing will break. The only thing that makes that promise affordable is being able to check before you press update, on every site, every month.
The work is verification, not clicking.
Applying updates takes seconds. Knowing they were safe is the part you are actually paid for, and it is the part that does not scale by itself.
A staging copy of every site, not a shared one
Checking an update means running it somewhere real first. Every site has its own staging environment, so a fifty-site plan is fifty rehearsals rather than one hopeful assumption.
A restore point taken before the patch
The fastest fix for a bad update is not debugging it. A snapshot immediately before the run turns a broken client site into a two-minute rollback.
Which sites are behind, at a glance
The hardest part of a care plan is knowing the current state of every site at once. Versions, pending updates and last-backup times are visible across the estate rather than site by site.
Reports the client believes
A monthly report you assembled by hand reads as marketing. One generated from what actually happened reads as work, and takes none of your time.
A compromised client is one client
Sites are isolated, so an infection on one does not become an incident across your whole book.
Care plans die on the tail.
Ninety per cent of updates are uneventful and take minutes. The last ten per cent eat the month, and the difference is whether you found them on staging or the client found them live.
- Per-site staging rather than a shared environment
- Snapshot taken immediately before each update run
- Estate-wide view of versions and pending work
- Reports generated from actual events
Fifty sites, one afternoon.
What matters is not how fast a single site is. It is how many sites one person can carry before the plan stops being profitable.
What we change for maintenance providers
You are not the end user of these sites. The tuning is about repeating the same job safely across a lot of them.
| Setting | What we do | Why |
|---|---|---|
| Staging | One environment per site rather than one shared | A rehearsal only tells you something if it runs against that site's actual plugin set, and a shared staging environment tests a configuration nobody runs. |
| Pre-update snapshots | Taken automatically before every update run | Rolling back is faster and more reliable than diagnosing a plugin conflict on a client's live site while they are watching. |
| Estate visibility | Versions, pending updates and backup status in one view | Checking fifty sites individually is the task that quietly consumes the margin a care plan is supposed to produce. |
| Reporting | Assembled from recorded events rather than by hand | A hand-written monthly report costs you the time you were paid for and still reads to the client like something you could have invented. |
| Isolation | Enforced between client sites | You carry the reputational risk for every site on your plan, so one compromised client has to stay one client's problem. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Do I get staging for every client site?
What happens when an update breaks a site?
Can I see which sites are out of date?
Do my clients see MagicWP?
Make the promise cheap to keep.
Move the care plan across - migration is free, every client site included.