Define Gravity - Managed Growth Infrastructure
Get a quote

Automattic and WebHosting.com: Platform Risk in Managed WordPress

For years, Automattic steered WordPress core while a large ecosystem of hosts sold the execution layer. The fight with WP Engine is a reminder that those two worlds were never as separate as the marketing suggested.

This perspective is for agencies, engineering leaders, and architects who still treat "open source CMS on a third-party host" as a clean way to avoid platform lock-in.

You can see the temperature in mainstream coverage and in curated timelines of the dispute, such as wpvswpe.report. The details matter, but the pattern is what architects should track: the steward of WordPress.org and a major commercial host are no longer pretending to be on the same team.

Two stacks, one brand

WordPress has always had two stories: the open project and the companies that monetize hosting around it.

Automattic already runs a vertical hosting stack. WordPress.com, Pressable, WordPress VIP, and WP Cloud are not side projects. They are the execution layer for a large share of the managed WordPress market.

Third-party hosts like WP Engine built businesses on the same software and the same org resources: plugin updates, directory access, and community trust in WordPress.org. That model worked when the relationship felt cooperative. It is harder to defend as a neutral architecture choice when the steward and the largest hosts are in open conflict.

When the platform owner pulls levers

The WP Engine dispute is not only a trademark argument. It is a reminder that WordPress.org and the plugin directory are infrastructure dependencies.

In September 2024, Matt Mullenweg publicly criticized WP Engine over trademark use and contributions to the project, as reported by outlets including the BBC and TechCrunch. Mutual cease-and-desist letters followed. Then WordPress.org blocked WP Engine from accessing org resources, which disrupted the normal path for plugin and theme updates for customers on that host.

October 2024 escalated further. WP Engine filed suit against Automattic and Mullenweg. Reporting described royalty demands tied to trademark licensing. WordPress.org assumed control of WP Engine's Advanced Custom Fields plugin, renaming it and pushing changes into a huge installed base. Access controls, including login requirements distancing WP Engine affiliates, turned identity on the org into part of the commercial fight.

In December 2024, a federal court granted WP Engine a preliminary injunction requiring Automattic to restore certain access and undo some restrictive measures, as summarized on wpvswpe.report. That matters architecturally: the levers were real, the harm was disputed, and courts became part of the control plane.

As of early 2026, amended complaints and public disputes over ecosystem tooling suggest the conflict is not closed. For operators, the lesson is not which side to cheer. It is that hosting WordPress at scale now includes landlord and governance risk alongside uptime.

WebHosting.com is a funnel, not a missing feature

Reporting on Whois changes suggests Automattic became registrant of WebHosting.com in 2026. That is less about new hosting technology than about owning a generic front door on the internet.

According to DomainInvesting.com (July 2026), historic Whois records show the name moving from AT&T to MarkMonitor with Automattic, Inc. as registrant. The site has carried a "coming soon" lander. This is consistent with a pipeline asset: intercept generic "web hosting" intent before a traditional host explains its plan.

Automattic does not need another control panel. It needs a category name that non-technical buyers already search for. Pair that with the WP Engine conflict and you get a coherent commercial strategy: contest large rivals while building a generic entry path into Pressable, WordPress.com, VIP, and WP Cloud.

State this carefully in your own materials: Whois evidence supports registrant control of the domain. A full corporate acquisition story may still depend on disclosures we have not cited here.

Bankruptcy of trust at the platform layer

Technical debt is code you regret. Ecosystem debt is trust you spend faster than you rebuild.

We use bankruptcy of trust in our technical-debt series for a reason. When users cannot complete the job they came for, the system has failed its social contract, not only its SLA. The WordPress market is running a version of that at the platform layer.

Agencies and enterprise teams often chose managed WordPress because the CMS was open and the host felt like a replaceable layer. You could argue about performance and support without feeling like you had bet the company on one SaaS landlord.

The WP Engine fight breaks that story. Trademark enforcement, blocked org access, plugin takeovers, and litigation tell architects something uncomfortable: scale on WordPress without alignment to Automattic's terms carries political and operational risk, not only technical risk.

That does not mean every host is unsafe tomorrow. It means neutrality was always partly fiction, and the fiction is harder to maintain now.

What belongs on your architecture checklist

Uptime and multi-region failover still matter. They are no longer the whole resilience picture.

If you run serious properties on WordPress, review platform risk next to availability:

  • Gatekeeper concentration: Who can change terms, APIs, branding rules, or access for your tier of host?
  • Exit cost: How painful is migration (DNS, edge, CI, licensed plugins, VIP-only features, support playbooks)?
  • Commercial overlap: Does your host compete with your business model in ways that invite conflict?
  • Org dependencies: How coupled are you to WordPress.org updates, directory policy, and plugin distribution?
  • Governance: Do contracts and escalation paths match the criticality of the property?

This is the same instinct as separating DNS from edge, or not treating one CDN as your only layer. You are asking who can move the floor under you, not only whether the servers are up. For the edge and DNS angle, see our perspective on when Cloudflare is down.

A practical posture without panic

You do not fix platform risk by rewriting everything on a Tuesday. You fix it by making dependencies explicit.

Document where WordPress sits in your stack: host, edge, DNS, email, CI, and who owns each contract. Name the properties that cannot tolerate a vendor fight or a surprise policy change. For those, bias toward portable patterns: standard deploy paths, fewer host-specific shortcuts, tested restore and migration.

For lower-stakes marketing sites, accepting Automattic-aligned hosting may be a rational trade. For regulated, high-traffic, or multi-brand estates, treat platform risk as architecture, the same way you treat key-person risk or unproven failover.

A managed infrastructure partner can help you harden the layers WordPress does not own: multi-region patterns, edge and DNS independence, observability, and rehearsed failover. The WordPress fight does not require abandoning the CMS. It requires honest dependency mapping.

Automattic's reported control of WebHosting.com points at owning the default search path into managed WordPress, while the WP Engine conflict shows the steward will pull org-level levers when commercial interests collide. That is not the end of WordPress in the enterprise. It is a reason to stop assuming open source alone insulates you from landlord risk. Resilience still includes uptime. It now has to include who holds the keys to your execution layer.

Sources