A self-hosted WordPress AI chatbot means one of two things, and the difference decides almost everything else. In the common setup, the plugin, its settings, its index and its conversation logs live in your WordPress install, but the answers come from a hosted model such as OpenAI, Anthropic or Google. In the strict setup, the model runs on hardware you control too, through a local inference server such as Ollama, llama.cpp or vLLM, so a visitor’s message never leaves your infrastructure. Both are possible on WordPress today: AI Engine, which showed 90,000+ active installations on its WordPress.org listing when I read it on 14 October 2026, supports the hosted providers and, through an OpenAI-compatible connector, local servers as well. I am building a WordPress chatbot called DFYe that is not on sale, so this is the map of the options rather than a pitch for one.
What actually counts as self-hosted?
The word gets used loosely, so it helps to name the three arrangements that exist and where a visitor’s message travels in each.
| Arrangement | Where the plugin and logs live | Where the model runs | Who sees each message |
|---|---|---|---|
| Hosted chatbot platform | Vendor’s servers | Vendor’s chosen provider | You, the platform, the model provider |
| WordPress plugin with a cloud model | Your WordPress install | OpenAI, Anthropic, Google or similar | You and the model provider |
| WordPress plugin with a local model | Your WordPress install | Your own server, via Ollama, llama.cpp or vLLM | You only |
Most people who search for a self-hosted chatbot want the second row and some want the third. The second already removes one party from the chain, the chatbot platform, and keeps your index and logs on your own hosting. The third removes the model provider as well, which is the only arrangement where messages stay entirely inside infrastructure you control.
Why do site owners want self-hosting?
Four reasons come up, and they lead to different answers.
Privacy and processor chains. Every company that handles visitor messages is another processor to name in your records, cover with an agreement and, if it sits outside the EEA, justify as a transfer. The GDPR’s article on processors sets out what that agreement must contain. Fewer parties means fewer agreements and a simpler notice. Our post on whether AI chatbots are GDPR compliant walks through the four decisions that matter.
Control over the index. With a plugin, the passages the bot answers from are built from your own pages inside your own database, and you can inspect, rebuild or delete them.
Cost predictability. A platform subscription grows with message volume. A plugin with your own key costs what the model provider charges per token, and a local model costs the server whatever the volume.
Independence. A plugin and a local model keep working if a vendor changes prices, terms or direction.
The first reason is the one that justifies running the model yourself. The other three are satisfied by the middle row of the table.
How do you run a WordPress chatbot on a local model?
The pieces are a model server, a model, and a plugin that can talk to the server.
- Choose a model server. Ollama is the simplest to install and runs open models with one command. llama.cpp is the lean engine many tools build on. vLLM is designed for serving many requests at once on a GPU. All three can expose an OpenAI-compatible API.
- Choose a model. Open-weight models come in sizes. Smaller models run on modest hardware and answer quickly; larger ones follow instructions better but need far more memory, usually a GPU.
- Place the server. On the same machine as WordPress only if that machine has the memory and CPU or GPU to spare. More often on a separate server on a private network, so a slow answer does not slow every page.
- Connect the plugin. In AI Engine, the custom OpenAI-compatible connector points at your server’s address. Other plugins that accept a custom base URL work the same way.
- Lock it down. The model server must not be reachable from the public internet. Bind it to a private address or put authentication in front of it.
- Test with your real questions, including questions your site does not answer, before switching the widget on.
What does each approach cost?
Exact prices change too often to quote responsibly, so the comparison below is about what you pay for rather than how much.
| Cost element | Cloud model via plugin | Local model you host |
|---|---|---|
| Model usage | Per token, billed by the provider | None per message |
| Hardware | None beyond normal hosting | A server sized for the model, often with a GPU, running all month |
| Setup time | An API key and a settings page | Server, model choice, networking, security |
| Maintenance | Plugin updates, key rotation | Plugin updates plus OS, server, model and security updates |
| Scaling with traffic | Automatic, cost rises with use | Fixed capacity; busy hours queue or need more hardware |
| Answer quality ceiling | The best hosted models | Whatever open model your hardware can run |
For a typical small business site, the cloud row is far cheaper: per-token prices published by the major providers put a month of modest chatbot traffic in the range of a few dollars, while a server able to run a capable model costs more than that every month before anyone asks a question. Self-hosting the model starts to make financial sense at high volume, or when the privacy requirement makes cost a secondary question. Our breakdown of what an AI chatbot costs covers the hosted side in detail.
Are local models good enough for a site chatbot?
Often, for the job a site chatbot actually does. When the bot uses retrieval, as described in how a RAG chatbot works, the hard part is finding the right passage from your pages. The model’s job is to read that passage and answer from it, which smaller models handle reasonably well.
Where smaller models struggle is the discipline around that job: refusing when no passage fits instead of improvising, sticking to the instruction to answer only from the context, handling unusual phrasing and staying polite under provocation. Those are exactly the behaviours that keep a site chatbot from embarrassing you. Test them specifically, with questions designed to tempt the bot off script, and compare a local model against a hosted one on the same set before deciding.
Does self-hosting make a chatbot secure?
It changes the risks rather than removing them. Removing the model provider removes one place your data could leak. It adds others: your own model server, which must not be exposed to the internet, and your own patching and monitoring, which is now your job rather than a vendor’s.
The risks specific to language models stay the same wherever the model runs. Prompt injection, where a visitor or a piece of content tries to override the bot’s instructions, is the first entry in the OWASP Top 10 for LLM applications and affects local models exactly as it affects hosted ones. So does the risk of a bot revealing information it should not, if the index contains pages that were never meant to be public.
Security under the GDPR is an obligation either way: the article on security of processing asks for measures appropriate to the risk, whoever runs the model.
When is self-hosting the wrong answer?
When the traffic is modest and nothing in the conversations is sensitive. A bakery answering questions about opening hours and allergens gains little privacy from running its own model and pays for it every month in hardware and attention. A plugin with a reputable hosted model, a short retention period and an honest notice is the proportionate setup there.
When nobody can maintain a server. A model server left unpatched and accidentally exposed is a worse privacy position than a hosted API with a processor agreement.
And when answer quality is the priority. If the best hosted models answer your hard questions correctly and the open models your hardware can run do not, the visitor experience should win, unless a legal requirement says otherwise.
It is the right answer for health, legal, financial and other sensitive contexts where messages may contain special category data, for organisations whose policy forbids sending such data to third parties, and for high-volume sites where fixed hardware costs less than per-token billing.
Where does DFYe fit?
DFYe runs inside WordPress: the passages come from the site’s own pages and stay in the site’s database, and the answer shows the passage it came from. That puts it in the middle row of the first table by design. It does not ship yet, so for a self-hosted chatbot on your site today, AI Engine with either a hosted key or a local server is the established route, and the setup above is how I would test it.
Key takeaways
“Self-hosted” means either a WordPress plugin whose index and logs live on your site while a cloud model answers, or a fully local setup where the model runs on your own server too. The first removes the chatbot platform from your processor chain; only the second keeps messages entirely in your infrastructure. AI Engine supports both, including local servers such as Ollama, llama.cpp and vLLM through an OpenAI-compatible connector. Self-hosting the model costs more for most small sites, needs real maintenance and does not remove prompt injection or your GDPR duties. Choose it when the privacy requirement or the volume is real, and test refusals before going live.
Questions people ask before moving
What is a self-hosted WordPress AI chatbot?
The phrase covers two different setups. In the common one, the chatbot plugin and its data live in your WordPress install, but answers come from a cloud model such as OpenAI or Anthropic. In the strict one, the model also runs on hardware you control, through a server like Ollama, llama.cpp or vLLM, so visitor messages never leave your infrastructure. Decide which one you need before choosing a plugin.
Can a WordPress chatbot run on a local model like Ollama?
Yes. AI Engine, the most widely used WordPress AI plugin with 90,000+ active installations on WordPress.org as read on 14 October 2026, offers an OpenAI-compatible custom connector that works with Ollama, LM Studio, vLLM, llama.cpp and similar servers. The model server can run on the same machine as WordPress if it is powerful enough, or on a separate server you control.
Is a self-hosted chatbot automatically GDPR compliant?
No. Self-hosting removes the model provider from the processing chain, which simplifies transfers and processor agreements, but you are still the controller with every obligation that brings: a lawful basis, an information notice, a retention period, security measures and a way to handle access and deletion requests. Self-hosting changes who processes the data, not whether the rules apply.
Are local models good enough for a website chatbot?
For answering from your own pages, often yes, because the hard part is retrieval and the model mainly has to read and summarise the retrieved passages. Smaller open models are noticeably weaker than the best hosted models at following strict instructions, refusing reliably and handling unusual phrasing. Test on your real questions, including ones the bot should refuse, before deciding.
When is self-hosting the model not worth it?
When your traffic is modest and nothing in your data is especially sensitive. A small site pays a few dollars a month in API usage for a hosted model, while a server capable of running a decent model costs more than that every month and needs updates, monitoring and security work. Self-host the model when the privacy requirement is real or the volume is high, not as a default.
