Course Recap: A Decision Framework for Self-Hosting
⏱ 10 min
This course started with a deliberately unglamorous claim: self-hosting an LLM is
usually not cheaper than paying for API tokens, once real GPU hardware and its ongoing
cost are counted honestly. Everything after that claim was about the three reasons
self-hosting is still worth doing anyway, privacy, regulatory and liability requirements,
and avoiding vendor lock-in, and the real, working infrastructure needed to act on those
reasons properly rather than half-way.
What you'll learn in this lesson
A full recap of what this course built
From the cost framework in Lesson 1 through a working, redaction-aware local RAG pipeline in Lesson 6.
A one-page decision framework
Something you can actually run against a new project before committing to any of this.
What stays exactly the same as a cloud setup
Data minimization, redaction, and most compliance obligations, none of which self-hosting removes.
Where to go from here
Back to Course 5 for provider fallback patterns, and Course 16 for the fuller compliance picture.
Prerequisites
All seven previous lessons in this course. This lesson doesn’t introduce new code, it
consolidates what you’ve already built and tested.
Step 1: What this course actually built
The seven lessons, in order
1. The decision
Self-hosting is a privacy and liability decision, not a cost optimization, for almost every real WordPress project.
2. Ollama
A local model running behind an OpenAI-compatible endpoint at http://localhost:11434/v1, confirmed with a plain curl request.
3. vLLM and llama.cpp
The same OpenAI-compatible shape, for higher GPU throughput or lower-resource hardware respectively.
4. The custom provider
A real ProviderInterface implementation registered with ProviderRegistry, verified directly against the SDK's own source.
5. Local RAG
Course 10's full retrieve-then-generate pipeline, running entirely against your own infrastructure for both embeddings and generation.
6. PII redaction
A regex-based redaction pattern applied before any prompt reaches your local provider, with its real limits stated plainly.
7. GDPR and EU AI Act alignment
The one genuine advantage (no cross-border transfer question), and everything that still applies exactly the same regardless of hosting.
Step 2: The decision framework, in one place
Lesson 1 introduced this checklist for a single project. Here it is again, now informed
by everything the rest of the course built, worth re-running whenever a new project
raises the self-hosting question:
Run this before starting any of this course's work on a new project
Is there a genuine privacy, regulatory, or contractual reason data can't reach a cloud AI vendor?
Not a vague preference, an identifiable requirement, a client contract clause, a data residency rule, a sector-specific restriction.
Does someone have the capacity to operate an inference server long-term?
Lesson 1's hardest question. Self-hosting relocates operational work, it doesn't remove it.
Have you priced the actual GPU and power cost against current cloud API pricing for this project's real traffic volume?
Not to prove self-hosting is cheaper, since it usually isn't, but to know the real number before committing.
Are PII redaction and data minimization already in place for the feature, regardless of hosting?
Lesson 6's discipline applies identically whether the model is local or cloud-hosted.
If the first answer is genuinely yes and the second is realistic, this course’s Lessons
2 through 6 are the concrete path from that decision to a real, working, tested
implementation.
It's fine to conclude self-hosting isn't the right call
A project that reaches this checklist and answers “no” to the first question hasn’t
wasted anything by asking. Going back to Course 5’s provider fallback patterns with a
cheaper cloud model is very often the right outcome, and recognizing that clearly is a
better use of engineering judgment than defaulting into self-hosting because it sounds
more serious or more private without a concrete reason behind it.
Step 3: What self-hosting doesn’t change
Worth restating plainly, since it’s the part most likely to get skipped under the
assumption that “local” means “automatically safe”: data minimization and PII redaction
from Lesson 6 still matter, your lawful basis and user-rights obligations under GDPR
still apply, and an AI feature’s EU AI Act risk tier still follows what it does, not
where it runs. Self-hosting solves the specific problem of data leaving your
infrastructure to reach an external AI vendor. It solves that problem well. It doesn’t
solve any of the others, and treating it as if it does is the most common mistake a team
makes right after getting a local model working for the first time.
Where to go from here
Course 5, PHP AI Client SDK
Revisit provider fallback and model preference patterns, the same mechanisms this course used to route calls to your local provider instead of a cloud one.
Course 10, RAG Knowledge Base for WordPress
The full pipeline this course's Lesson 5 adapted, worth a deeper look if you skipped straight to this course.
Course 16, AI Governance, Compliance & Responsible AI
The fuller GDPR and EU AI Act picture this course's Lesson 7 built on rather than re-derived.
Recap
Self-hosting an LLM for WordPress is a real, defensible architecture when privacy,
regulatory requirements, or vendor lock-in are genuine concerns for a specific project,
and a real, working custom provider for the PHP AI Client SDK, built on the same
ProviderInterface and ProviderRegistry an official provider plugin uses, is what
turns that decision into working code rather than a slide in a planning document. None
of it removes the discipline the rest of this track already taught: minimize what a
prompt contains, redact what you can, and document what a compliance reviewer would
actually need to see. Self-hosting changes where the model runs. It doesn’t change what
responsible AI engineering on WordPress requires.