Connecting a self-hosted Ollama server to WordPress, and why localhost fails

What they built

More WordPress plugins let you bring your own AI, and many support Ollama, so drafts like page titles and meta descriptions can come from an open model on hardware you control, with no API key, no per-request bill and no content leaving your infrastructure.

The catch is that the plugin's request is made by PHP on the web server, so http://localhost:11434 means the web server itself, not your laptop. The guide covers where Ollama has to live for that to work, how to expose it safely, and how to test the connection from the WordPress side before blaming the plugin.

In the author's own plugin, Coretex SEO, suggested titles and meta descriptions land in a review queue with Edit, Apply and Dismiss, so a person still decides what reaches the live page.

Setup

• Ollama on a Linux server, either the same VPS as WordPress or a separate machine such as a GPU box the web server can reach
• llama3.2 as the example model, pulled on the Ollama server
• A firewall (ufw) or a private network such as a provider VPC, WireGuard or Tailscale between the two servers
• WP-CLI for testing from PHP inside WordPress

How it works

1. Same server as WordPress: leave Ollama on its default 127.0.0.1:11434 and use http://localhost:11434 in the plugin.
2. Separate server: set OLLAMA_HOST to a private network address in a systemd override, so the web server can reach it but the internet can't.
3. Because Ollama's API has no authentication and many plugins send no Authorization header, protection is at the network level: allow only the WordPress server's IP to port 11434.
4. Requests use "stream": false so Ollama returns one JSON object with the full answer in its response field, the format most PHP integrations expect.

Results & numbers

• Ollama on the same VPS works with the default localhost URL; Ollama on a reachable separate machine works with that machine's address.
• Ollama on your laptop with WordPress on a host, or anything on shared hosting, won't work.

Gotchas

• It works on a local dev laptop and breaks the moment you deploy, because localhost now means the web server.
• Binding to 0.0.0.0 listens on every interface, including the public one, and leans entirely on your firewall.
• cURL error 7 means PHP can't connect (bind address or firewall); cURL error 28 is a timeout.
• The first request is slowest because Ollama loads the model, and it unloads idle models after a few minutes; OLLAMA_KEEP_ALIVE changes that.
• CPU-only inference on a large model may take longer than the plugin will wait, so try a smaller model first and keep batches small.
• Plugins generally can't pull models for you, so 'model not found' means you haven't pulled it on the Ollama server.

“Local models are useful drafters, not editors.”— John Rotherham

Do it yourself

1. Install Ollama on the server and pull a model: curl -fsSL https://ollama.com/install.sh | sh, then ollama pull llama3.2.
2. If Ollama is on a separate machine, run sudo systemctl edit ollama.service, set Environment="OLLAMA_HOST=<private-ip>:11434", then daemon-reload and restart.
3. Allow only the WordPress server to reach port 11434 with ufw, or keep the traffic on a private network.
4. SSH into the WordPress server and test with curl against /api/tags and /api/generate.
5. Test from PHP with a small wp_remote_post script run through wp eval-file.
6. Enter the server URL and model in your plugin's settings and run its connection test.

sudo ufw allow from 203.0.113.10 to any port 11434 proto tcp
sudo ufw deny 11434/tcp
curl http://10.0.0.5:11434/api/generate \
  -d '{"model": "llama3.2", "prompt": "Write a page title for a bakery in Leeds.", "stream": false}'