Connecting a Self-Hosted Ollama Server to WordPress (and Why localhost Won't Work)

John Rotherham — Wed, 21 Oct 2026 14:13:07 +0000

More WordPress plugins now let you "bring your own AI": paste in an API key and the plugin sends prompts to OpenAI, Anthropic or whoever you choose. Many also support Ollama, which runs open models on hardware you control. No API key, no per-request bill, and your content doesn't leave your infrastructure.

It sounds simple: install Ollama, point the plugin at http://localhost:11434, done. Then the connection test fails, and it's not obvious why.

This post walks through connecting a self-hosted Ollama server to WordPress properly: where Ollama needs to run, how to expose it safely, and how to test the connection from the WordPress side before blaming the plugin.

The localhost trap

Here's the bit that catches people out. When a WordPress plugin calls http://localhost:11434, the request is made by PHP on the web server. "localhost" means the web server itself, not your laptop.

So:

Ollama on your laptop + WordPress on a host: won't work. The host can't see your laptop's localhost.
Shared hosting: won't work. You can't install and run a long-lived Ollama process there, and the server won't have the memory for a model anyway.
Ollama on the same VPS or dedicated server as WordPress: works with the default localhost URL.
Ollama on a separate machine (say, a GPU box) that the WordPress server can reach: works, with the server's address instead of localhost.

If you develop locally with WordPress and Ollama on the same laptop, localhost works fine. It breaks the moment you deploy, which is why it's worth understanding now.

Step 1: Install Ollama and pull a model

On a Linux server:

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.2
ollama list

The model has to be pulled on the Ollama server before any plugin can use it. Plugins generally can't pull models for you. llama3.2 is just an example here; pick whatever fits your hardware, and test the output quality on your own content before relying on it. Smaller models run faster on modest hardware; larger ones need much more RAM or a GPU.

Step 2: Decide what Ollama listens on

By default, Ollama listens on 127.0.0.1:11434, so only the same machine can reach it.

Same server as WordPress? Leave it alone. Use http://localhost:11434 in the plugin.

Separate server? Tell Ollama to listen on an address the WordPress server can reach. With the Linux install it runs as a systemd service, so add an override:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=10.0.0.5:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Bind to a private network address (like 10.0.0.5 above) if your two servers share one. 0.0.0.0 also works, but it listens on every interface, including the public one, so it leans entirely on your firewall.

Step 3: Lock it down

Ollama's API has no built-in authentication. Anyone who can reach port 11434 can run prompts on your hardware. And many WordPress integrations send a plain request with no Authorization header, so putting an auth-checking reverse proxy in front won't help unless the plugin supports it.

That means the protection has to be at the network level:

# Allow only the WordPress server to reach Ollama
sudo ufw allow from 203.0.113.10 to any port 11434 proto tcp
sudo ufw deny 11434/tcp

Better still, keep the traffic on a private network between the two servers (your provider's VPC, or a WireGuard/Tailscale link) so port 11434 never faces the internet.

Step 4: Test from the WordPress server's shell

Before touching WordPress, SSH into the WordPress server (not your laptop) and check that it can reach Ollama:

# Can we connect, and which models are installed?
curl http://10.0.0.5:11434/api/tags

# Does generation work?
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}'

"stream": false returns one JSON object with the full answer in its response field, instead of a stream of chunks. That's the format most PHP integrations expect.

If the first command hangs or says "connection refused", it's the bind address or the firewall. If the second complains that the model isn't found, you haven't pulled it on that server.

Step 5: Test from PHP inside WordPress

The shell test proves the network path. This one proves PHP and the WordPress HTTP API can use it too. Save as ollama-test.php and run it with WP-CLI:

<?php
// Run with: wp eval-file ollama-test.php
$url = 'http://10.0.0.5:11434/api/generate';

$response = wp_remote_post( $url, array(
    'timeout' => 60,
    'headers' => array( 'Content-Type' => 'application/json' ),
    'body'    => wp_json_encode( array(
        'model'  => 'llama3.2',
        'prompt' => 'Write a meta description for a bakery in Leeds.',
        'stream' => false,
    ) ),
) );

if ( is_wp_error( $response ) ) {
    WP_CLI::error( $response->get_error_message() );
}

$code = wp_remote_retrieve_response_code( $response );
$data = json_decode( wp_remote_retrieve_body( $response ), true );

WP_CLI::log( $code . ': ' . ( $data['response'] ?? $data['error'] ?? 'Empty body' ) );

wp eval-file ollama-test.php

A cURL error 7 here means PHP can't connect, which is the same network problem as Step 4. A cURL error 28 is a timeout, which brings us to performance.

Step 6: Mind the timeouts

Plugins set their own HTTP timeouts, and a local model on modest hardware can be slow:

The first request is the slowest, because Ollama loads the model into memory. By default it unloads an idle model after a few minutes; the OLLAMA_KEEP_ALIVE environment variable changes that.
CPU-only inference on a large model may simply take longer than the plugin is willing to wait. If you see timeouts, try a smaller model before anything else.
Batch jobs add up. If a plugin processes several pages per run, each one is a separate request. Start with small batches.

Step 7: Point the plugin at it

Once the WP-CLI test passes, the plugin side is usually just a URL and a model name. As one example, in Coretex SEO (the plugin I work on) it's Coretex SEO → ⚙ Settings → AI Engine Settings: choose an Ollama model in Brain (Provider + Model), enter the Ollama Server URL, then click Save Settings and Test Connection. There's no key field for Ollama. Its scans then put each suggested title or meta description into a review queue with Edit | Apply | Dismiss, so a person still decides what reaches the page. One limit worth knowing: it talks to your own Ollama server only, so Ollama Cloud isn't supported.

Other plugins differ in labels, but the checklist is the same: the URL must be reachable from the web server, and the model must already be pulled there.

Troubleshooting cheat sheet

Symptom	Likely cause	Fix
Works locally, fails after deploy	`localhost` now means the web server	Run Ollama on that server, or use a reachable address
Connection refused / cURL error 7	Ollama bound to 127.0.0.1, or firewall	Set `OLLAMA_HOST`, open the port to the WP server only
Timeout / cURL error 28	Model too big for the hardware, or cold start	Smaller model, warm it up, `OLLAMA_KEEP_ALIVE`
"model not found"	Model not pulled on that server	`ollama pull <model>` on the Ollama server
Works on shared hosting?	It won't	Use a VPS or dedicated server

Wrapping up

Self-hosting the model behind your WordPress AI features is very doable, as long as you remember that the request comes from the web server. Put Ollama where the web server can reach it, keep port 11434 off the public internet, and test from the WordPress server's own shell and PHP before you blame the plugin.

And whatever the model writes, keep a human between its output and your live pages. Local models are useful drafters, not editors.

This article was written with the help of AI and checked by the author.

DEV Community: John Rotherham