Self-Hosted WordPress: the Maintenance You Are Taking On

The hosting bill for a self-hosted site is small and visible, which is why the comparison against managed hosting usually ends there. The rest of the cost is a task list that repeats forever: update the plugins, check the backup, read the logs, renew the certificate, watch the disk, patch PHP, audit the users. None of it is difficult. All of it has to happen on a schedule that does not care whether anyone is on holiday.

That is the honest description of self-hosting. It is not worse than managed hosting; it is a different allocation of work. The managed premium buys the schedule, the monitoring and the person who picks up the ticket. Self-hosting keeps that money and spends it as attention, spread across the year in small, easily deferred pieces.

The purpose of this article is to make the work visible, so the choice can be made with a number instead of a feeling. The calendar below is realistic for a small business site, a store, or a handful of client sites. It is not every possible task. It is the set that, if skipped, produces the failures that fill support queues.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. That does not change the price, and it does not change the recommendation below, which includes the case for not buying hosting at all.

Self-hosting is a maintenance contract with yourself

Managed hosting sells four things: a maintained platform, a backup and restore process, a security layer, and someone to call. Self-hosting means owning all four. The platform is the server you rent. The backup is the job you configure. The security layer is the firewall, the updates and the permissions you set. The someone to call is you, or the person you pay when it breaks.

The first year is usually fine, because the site is new and the plugins are current. The problems accumulate in the second and third years, when a plugin is abandoned, PHP reaches end of life, a certificate renewal fails, or the person who set it up has moved on. That is the shape of self-hosted maintenance: low effort early, compounding debt later, unless the calendar is real.

None of this argues for managed hosting by default. A technically confident owner with a small site can run it well for years. The argument is for counting the hours honestly before deciding that the cheaper plan is cheaper.

The monthly hour

Once a month, block an hour. Not five minutes, because the five-minute version is "click update" and it is how sites end up on an old plugin for a year. The hour covers updates, verification and a look at the things that only show up when someone looks.

• Updates: core, plugins and themes, with a backup taken first and a staging check for anything major. Read the changelog for a plugin that touches checkout or forms.
• Backup verification: confirm the newest archive exists, has a plausible size and is on the off-host destination. Not the plugin's green tick; the object list.
• Log review: the PHP error log and the access log, looking for repeated 500s, a new spike in a path, or a login pattern that does not match the team.
• Disk and database: check free space and the size of the largest tables. A log table that doubled is a warning before it is an outage.
• Admin list: new users, new administrators, application passwords that nobody claims.

That is the hour. It is not glamorous and it prevents most of the failures that would otherwise become incidents. The trick is to put it in the calendar as a recurring event with a checklist attached, so it does not depend on remembering.

The quarterly half-day

Four times a year, take half a day. This is where the work that cannot be done in an hour lives: version checks, access reviews, a restore drill and a performance baseline. Divide it into four blocks so it does not turn into an afternoon of browsing dashboards.

The restore drill is the block most often skipped and the one that pays the most. It is covered in detail in its own article, and the short version is: restore the archive, walk a fixed list, write down the time. Quarterly is enough for a small site. Monthly is better for a store.

The access review is the other block with a habit problem. It is easy to check the WordPress users and forget the hosting panel, the database users, the SSH keys and the API keys. Those are the credentials that survive staff changes, and they are the ones nobody remembers issuing.

The annual day

Once a year, take a day and look at the site as a system rather than a collection of screens. PHP versions reach end of life on a published schedule, and the host will eventually stop offering the old one. Database engines do the same. A plugin that was fine two years ago may now be abandoned, and the theme may have moved to a new major version with a migration path.

Renewals belong here too: hosting, domain, TLS, plugin licences, backup storage. Put every renewal in one calendar with a reminder two weeks before, because an expired card is one of the most common causes of a site going dark. Check that the payment method is current and that the billing email is one a human reads.

Then the capacity question. The plan that was right for last year's traffic may be wrong for this year's, in either direction. Look at the visitors, the PHP workers, the disk and the database size, and compare them with the plan limits. Moving to a larger plan proactively is cheaper than discovering the limit during a launch, and moving down is money back.

Finally, the architecture review. Is the site still doing what it was built to do? Are there plugins that could be replaced by core? Is the staging environment still a copy of production, or has it drifted? Has the backup destination been tested from outside the account? An hour of questions here saves a quarter of firefighting later.

The tasks that surprise people

Three dependencies fail silently and are nobody's obvious job. Email is the first: a self-hosted site that sends mail from the web server is likely to land in spam, and configuring SMTP, SPF, DKIM and DMARC is a project rather than a checkbox. A transactional mail provider solves it and adds an account to maintain. The failure mode is a password reset that never arrives, discovered by a locked-out customer.

Cron is the second. WordPress's own cron runs when a request arrives, so a quiet site can miss its backup window, and a busy site can run the same job twice. The fix is a real system cron calling wp cron event run --due-now every few minutes, which requires shell access and a note in the runbook. Without it, scheduled posts, subscriptions and backups all depend on traffic.

DNS is the third. It is set once and forgotten, which is fine until a renewal, a host move or a mail change. Keep the zone exported, keep the registrar account with two-factor authentication, and keep the TTL low enough that a change takes minutes rather than hours. None of that is hard. All of it is invisible until it is urgent.

When the hours cost more than the plan

Add the calendar up. The monthly hour is twelve hours a year. The quarterly half-day is sixteen. The annual day is eight. That is thirty-six hours before any incident, any migration, any plugin conflict, any security cleanup. Put an hourly rate on it, even a modest one, and compare the total with the managed premium for the same site.

For many owners the arithmetic is close, and the deciding factor is not money but attention. A managed plan is worth it when the hours are the bottleneck: a solo founder, an agency with more sites than staff, a store where an hour of downtime costs more than a year of premium. Self-hosting is worth it when the owner enjoys the work, the site is small, and the hours are available.

The hosting choice itself should follow the maintenance plan. SiteGround includes staging, daily snapshots and a panel that handles the common operations, which shortens the monthly hour. Hostinger's referral link gives the reader a discount on the first term, and WPSifero earns the same percentage the reader saves; check the cart for the current figure and the term it applies to. Jetpack's backup and scan modules cover two of the monthly tasks from outside the server, which is useful when the server is the thing being maintained.

Where self-hosting is the wrong choice: a business owner who does not want to read a changelog, on a site that takes payments and holds customer data. The saved premium is smaller than the cost of the first missed update. The decision rule is the calendar: if the thirty-six hours are not realistically available, the managed plan is not an expense, it is a purchase of the time.

The minimum viable maintenance plan

1. Monthly: backup, update, read the logs, check disk and administrators.
2. Quarterly: restore drill, access audit, PHP and database versions, performance baseline.
3. Annually: renewals, PHP end-of-life check, plugin audit, capacity review, architecture questions.
4. Always: system cron, SMTP with SPF and DKIM, exported DNS zone, off-host backup.
5. In writing: who does each task, where the credentials are, and what to do when the site is down.

That is the whole plan. It is smaller than the anxiety around self-hosting suggests, and larger than the "it just works" pitch admits. The site will be fine for as long as the calendar is real.