TechEarl

When Agencies Should Self-Host WordPress (and When They Should Not)

Self-hosting WordPress as an agency is one of the most consequential operational decisions you can make. The four conditions under which self-hosting is the right call, the four under which it is a mistake, and the honest math on the long-term cost.

Ishan Karunaratne⏱️ 8 min readUpdated
Share thisCopied
Self-hosting WordPress as an agency. Four conditions for yes, four for no, and the honest math on long-term operational cost. From a CTO who self-hosts.

Self-hosting WordPress as an agency is one of the most consequential operational decisions you can make. Done right, it is the foundation of a 50%+ margin on hosting revenue and full control over the stack. Done wrong, it is the source of weekend outages, security incidents, and the slow erosion of agency profitability as senior people spend more time on infrastructure than on client work. The decision has four "yes" conditions and four "no" conditions, with most agencies sitting in the "no" camp. Here is the honest framework.

Jump to:

The four conditions for "yes, self-host"

All four should be true. If any are missing, self-hosting is the wrong call.

1. You have real Linux sysadmin skill in-house. Not "I can SSH and run commands." Real skill: nginx tuning, systemd, MySQL configuration, fail2ban, certbot, automated backups, OS patching, security incident response. If the answer to "what would you do if the site got hit with a memory exhaustion attack" is "I would Google it," you do not have the skill yet.

2. You have 20+ client sites to spread the operational cost across. A single VPS hosting 1-3 sites is more expensive per site than managed WordPress because the operational time amortizes badly. The break-even is around 5-8 sites per VPS; the comfort zone starts around 15-20.

3. You have client workloads that genuinely benefit from custom configuration. If every client site is a standard marketing site that managed WordPress hosts handle well, you are paying the self-hosting tax without getting the benefit. Self-hosting wins when sites have specific requirements (custom MySQL tuning, specific PHP modules, unusual cron patterns, very-large directory architectures).

4. You have agreed (and budgeted) that the agency owner or a senior person is on-call for production incidents. Outages happen at 3am. Self-hosting means the response is yours. If nobody on the team is willing to take that call, do not self-host.

The four conditions for "no, do not self-host"

If any one of these is true, do not self-host.

1. The agency owner is the only technical person and is already overcommitted. Adding "production sysadmin" to an already-full plate guarantees something gets dropped. Managed hosting buys back that capacity.

2. The agency hires junior developers but not sysadmins. Junior front-end developers are abundantly available; junior sysadmins for WordPress are not. Self-hosting requires senior-level skill that is hard to hire and expensive to retain.

3. The agency client portfolio is under 10 sites. The economies of scale that justify self-hosting do not exist yet. Wait until the portfolio grows.

4. Compliance is the client's primary concern. HIPAA, SOC 2, PCI-DSS, and similar compliance regimes are easier to demonstrate on a hosting provider that has the certifications baked in. Self-hosting requires you to maintain the compliance posture yourself, which is a real ongoing cost.

The hidden costs of self-hosting

The costs that do not show up in the hosting bill but always show up in agency profitability:

  • OS patching every 4-6 weeks. 30-60 minutes of careful work per server. If you have 5 servers, that is 3-5 hours every 6 weeks.
  • WordPress core updates per site. Trivially scriptable but adds up across the portfolio.
  • PHP major-version upgrades every 1-2 years. Real work; possible plugin compatibility issues.
  • MySQL major-version upgrades every 2-3 years. More disruptive than PHP upgrades.
  • Server replacement every 3-4 years. A full migration from old infrastructure to new is a multi-day project.
  • Security incident response. Rare on a well-hardened setup, brutal when it happens. Compromised sites can take days to clean up.
  • Backup verification and disaster recovery drills. Quarterly minimum. Nobody does this enough.
  • Monitoring and alerting maintenance. Alert fatigue is real; tuning is ongoing.
  • Documentation upkeep. What you set up today, you will need to remember in 18 months. Document or suffer.

Total: easily 20-30 hours per month of senior engineering time, across all the servers and all the sites. Multiply by senior rate; that is your self-hosting tax.

What "good" self-hosting actually looks like

For agencies that DO self-host successfully, the patterns:

  • Standardized server setup. Every server provisioned identically via Ansible, Terraform, or similar. No snowflake servers.
  • Multi-tenancy on each VPS. 10-30 small sites per server, isolated via separate users and PHP-FPM pools.
  • Automated provisioning for new client sites: a script that creates the user, sets up nginx, installs WordPress, requests SSL, configures backups.
  • Centralized monitoring with alerting routed somewhere humans actually look (PagerDuty, OpsGenie, or a Slack channel that is actually watched).
  • Off-site backups daily, tested quarterly. Not "backups exist"; backups RESTORE.
  • Documented runbooks for every recurring task. New team members can do routine operations without senior help.
  • A real on-call rotation. If you have multiple technical people, on-call rotates. If you are solo, on-call is just "your phone, always."

This setup is achievable for agencies with the right team. It is not "buy a Hetzner box and figure it out as you go."

The 3am test

The single best decision-making question: if a client site goes down at 3am on a Saturday, who fixes it, how quickly, and what is the impact on the rest of the weekend?

  • Managed WordPress: the host's NOC fixes it. You get a notification email Monday morning. Impact: zero.
  • Self-hosted: you fix it. Depending on the issue, this is 30 minutes to 6 hours of focused work, plus the wake-up and the after-effects.

If you have done this self-hosted incident response before and it does not bother you, self-hosting is in your wheelhouse. If the thought of being paged at 3am makes you reach for managed hosting, listen to that instinct.

Migration paths if you started in the wrong place

If you self-host and realize you should not have:

  • Pick a managed WordPress provider (Kinsta, WP Engine, Cloudways).
  • Migrate sites in waves of 5-10 over a few months. Most managed hosts have free migration services for new customers.
  • Pass the per-site cost increase through to clients as a "infrastructure upgrade" line item.
  • Retire your VPS infrastructure after the last migration.

Total transition time for a 30-site portfolio: 2-3 months. Cost is real but the operational relief is dramatic.

If you are on managed WordPress and considering self-hosting:

  • Do not migrate client sites first. Start with internal projects.
  • Build the operational infrastructure (monitoring, backups, provisioning, on-call) before any client load.
  • Migrate one low-stakes client site after the infrastructure is proven. Run it for 3 months. Address every issue that surfaces.
  • Only then consider broader migration.

This is the slow path that lets you abort cleanly if self-hosting turns out to be harder than expected.

How AI changes the calculus

AI-assisted infrastructure (covered in Using AI to Help Manage WordPress Infrastructure and AI for WordPress Sysadmins) reduces but does not eliminate the operational burden. The AI is good at log triage, config audits, deploy verification, and incident triage. It does not make the 3am page go away; it just makes the response faster once you wake up.

The net effect: AI shifts the break-even point a bit. The "20+ sites to justify self-hosting" rule of thumb might be closer to "15+ sites with AI in the loop." But the fundamental question (do you have the skill, the time, and the on-call willingness) is unchanged.

For the broader hosting decision framework, see A WordPress Hosting Decision Tree for Agencies. For the managed vs VPS comparison specifically, see Managed WordPress Hosting vs VPS for Agencies. For how hosting decisions feed into agency profitability over time, see How Hosting Choices Affect Agency Profitability.

Sources

Authoritative references this article was fact-checked against.

TagsWordPressHostingAgencySelf-HostingOperations

Found this useful? Pass it on.

Copied

Ishan Karunaratne

Tech Architect · Software Engineer · AI/DevOps

Tech architect and software engineer with 20+ years building software, Linux systems, and DevOps infrastructure, and lately working AI into the stack. Currently Chief Technology Officer at a healthcare tech startup, which is where most of these field notes come from.

Keep reading

Related posts

WP Engine for WordPress Agencies: Honest Review

WP Engine is the most-recognized managed WordPress host and the default pick for many agencies. The honest take on performance, support, the agency partner program, the recent ACF acquisition implications, and where WP Engine wins or loses against alternatives.

AI for WordPress Agency Operations: The Playbook

The agency-ops playbook for AI: proposals, SOWs, onboarding documents, SOP creation, meeting summaries, status reports, internal documentation. Where the per-hour gain is highest, and the rules that keep client trust intact.