Should You Self-Host AI for WordPress? An Honest Framework

Somewhere in almost every conversation about self-hosted AI, someone frames it as a cost optimization: “if we run our own model, we stop paying per token.” That’s the wrong starting point, and building a whole architecture on it tends to produce a worse outcome than just picking a cheaper cloud model would have. This lesson works through the actual cost math, then lays out the three reasons self-hosting genuinely does make sense, so the rest of this course is something you reach for deliberately, not by accident.

What you'll learn in this lesson

The cost math nobody wants to do

Why GPU hardware and its ongoing cost usually beat API tokens on a pure price comparison, not the other way around.

The three real reasons to self-host

Privacy, regulatory and liability requirements, and avoiding vendor lock-in, none of which are "it's cheaper."

When self-hosting is clearly not worth it

Low-volume features, small teams, and no regulatory pressure.

A short decision checklist

Something you can actually run against a real project before committing engineering time to this course.

Prerequisites

Course 5’s PHP AI Client SDK foundation, so you have a baseline for what calling a cloud provider actually costs and involves. No new WordPress APIs are introduced in this lesson, it’s entirely about the decision that precedes writing any code.

Step 1: Do the cost math before you do anything else

A GPU capable of running a genuinely useful open-weight model at reasonable speed is not a small purchase, and it doesn’t stop costing money once you own it: it draws power continuously if you keep a model loaded and ready to answer requests, it needs a machine around it, and someone has to keep the drivers, the inference server, and the underlying OS patched. None of that shows up on an API invoice for a cloud provider, where the listed per-token price already has all of that folded in and amortized across every other customer sharing the same infrastructure.

# File: terminal - a rough, illustrative comparison, not a quote
# Cloud API: pay only for tokens actually used, no idle cost, no hardware to own.
# Self-hosted: pay for the GPU whether it answers 10 requests today or 10,000,
# plus power, plus whoever's time it takes to keep the box running.
echo "Before committing to self-hosting, estimate: (GPU cost + power + maintenance time)"
echo "over your project's real timeline, and compare that number to what the same"
echo "traffic would actually cost against a cloud provider's current per-token pricing."

For most WordPress projects, at most traffic volumes, that comparison favors the cloud API, sometimes by a wide margin. Specific GPU prices and specific per-token prices both change constantly, so treat the exercise above as a method to run yourself with current numbers, not a fixed conclusion to quote later.

Idle cost is the part people forget

A cloud API charges nothing while nobody is using your feature. A GPU you own or rent keeps costing money whether it’s answering requests or sitting idle, unless you’re disciplined about spinning it down between uses, which then reintroduces cold-start latency you didn’t have with a cloud API in the first place.

Step 2: The three real reasons to self-host

If cost isn’t the case, what is? Three reasons hold up under real scrutiny, and they’re the reasons this course actually exists for.

Real reasons to self-host, in order of how often they actually apply

Privacy: no data ever leaves your network

The strongest, simplest case. If a prompt never crosses your own infrastructure boundary, there is no third-party data processor to worry about for that specific call.

Regulatory or liability requirements

Data residency rules, contractual terms with a client that forbid sending their data to an external API, or sector-specific rules (healthcare, legal, government) that make a third-party AI processor a hard blocker.

Avoiding vendor lock-in

A team that has decided depending entirely on one AI vendor's pricing, uptime, and policy decisions is itself a risk worth engineering against, independent of any single feature's economics.

Every one of these is a real, defensible engineering reason. None of them is “it will be cheaper.” If your actual driver is one of these three, the rest of this course is worth the investment. If it isn’t, say so honestly before writing any code.

Step 3: When self-hosting is clearly not worth it

The inverse case matters just as much. A low-traffic admin tool that runs a handful of AI requests a day, on a small team with no regulatory constraint and no contractual restriction on where data goes, gains nothing from self-hosting and takes on real, ongoing operational cost: someone has to run the inference server, keep the model updated, monitor it, and handle its downtime, work a cloud provider was doing for you.

Self-hosting doesn't remove operational work, it relocates it

Every reliability, availability, and maintenance concern that used to be a cloud provider’s job becomes your team’s job the moment you self-host. That’s a legitimate trade for the three reasons in Step 2. It’s a bad trade if none of those three reasons actually apply to your project.

Step 4: A decision checklist for a real project

Before starting Lesson 2, run an actual project through this list:

Does this feature process data with a genuine privacy sensitivity?

Health information, legal content, anything a client has explicitly restricted.

Is there an actual regulatory or contractual reason data can't leave your infrastructure?

Not a vague sense that it might be a problem, an identifiable rule or clause.

Is vendor lock-in a real, named risk for this project?

Discussed and agreed on by the team, not a hypothetical.

Does someone on the team have the capacity to operate an inference server long-term?

This is the ongoing cost self-hosting actually saves you from, if the answer is no.

If none of the first three are genuinely true, stop here and use Course 5’s provider fallback patterns with a cloud model instead. If at least one is true and the fourth is also true, continue to Lesson 2.

Test it: write down your own project’s answer

Before moving on, write a single sentence naming which of privacy, regulatory requirement, or vendor lock-in avoidance is the actual reason you’re considering self-hosting for a specific project. If you can’t complete that sentence honestly, that’s useful information too.

Recap

Self-hosting an LLM is very rarely a cost optimization once GPU hardware and its ongoing upkeep are counted honestly against per-token cloud pricing. The real reasons it makes sense are privacy, regulatory or liability requirements around data residency, and avoiding dependence on a single AI vendor. Where none of those apply, a cheaper model in a Course 5 preference list is almost always the better engineering decision. Where one or more genuinely does apply, the rest of this course builds the real infrastructure for it.

When Self-Hosting AI Actually Makes Sense