Why we ship Go alongside PHP for some clients

I have been writing PHP for 18 years and Go for about 15. WordPress sites I manage run PHP, because that is what WordPress is. But on a handful of client projects, there is a Go binary running quietly alongside PHP, doing one specific job. Running Go alongside PHP is not always the right call, but when it is, the combination is hard to beat. This post is about why, and when that combination makes sense for a small business.

The thing PHP is bad at

PHP is excellent at request-response cycles. A browser asks for a page, WordPress runs, the page renders, PHP exits. The whole machinery exists to serve that pattern, and it serves it well.

What PHP is bad at is long-running processes. Anything that needs to stay resident, hold open connections, run on a schedule independent of HTTP traffic, or process a queue in the background, PHP can do but does awkwardly. WP-Cron is the classic example. It is not a real cron. It only runs when someone visits the site, which means a low-traffic site has unreliable scheduled tasks, and a high-traffic site has a hidden performance tax on every visitor.

You can paper over this with a system cron calling WP-CLI, or a Supervisor process running a PHP daemon, or a queue worker like Action Scheduler. These work. They are also fragile in ways that show up six months later, usually when nobody remembers the configuration.

What Go is good at

Go is built for exactly the kind of workload PHP struggles with. A Go binary compiles to a single executable, holds memory cheaply, handles thousands of concurrent connections without breaking a sweat, and runs as a long-lived process that systemd or any init system can supervise reliably.

It is also boring to deploy. There is no language runtime to install on the server. The binary you compiled is the binary the server runs. No version drift between environments. No dependency hell. The first time you ship a Go binary to a production VPS, the experience is suspicious. It just works.

Where running Go alongside PHP has actually paid off

The pattern is consistent. WordPress runs the public site, the admin, the content, the forms, everything a client interacts with through a browser. A small Go service runs in the background doing the one thing PHP would do badly.

Some examples from real projects:

Scheduled data fetches. A site that pulls in inventory or rates from a third-party API every 15 minutes. PHP can do this through WP-Cron, but the failure modes are bad. A Go daemon hits the API on a real schedule, writes to a JSON file or directly to the WordPress database, and exits silently if the API is down. The PHP side reads what is there. The fetch and the render are decoupled.

Aggregation pipelines. One client needed to pull articles from 30 RSS feeds and surface the most-discussed stories. The fetch, dedupe, cluster, and rank logic is 600 lines of Go. The WordPress front-end queries a SQLite database the Go service writes to. The whole pipeline runs in under 4MB of memory and updates every 10 minutes. Trying to do that in PHP would have meant a queue worker, a Redis instance, and three plugins.

Webhook receivers. When a third-party service needs to POST to your site dozens of times per minute, sending those requests through WordPress means booting the full WP stack on every hit. A 50-line Go service can receive the webhook, validate it, and either queue it for WordPress to process later or write directly to the database. PHP only runs when a human needs it to.

When it is not worth it

Most clinic sites should not have a Go service running alongside PHP. If your background work is a daily backup, an hourly cache warmer, and a weekly database optimization, WP-CLI plus system cron is fine. Adding a second language adds a second thing to maintain, and the cost of that is real.

The threshold I use: if the background job runs more than once an hour, or holds open connections, or processes events faster than once a minute, Go starts to make sense. Below that, stick with PHP. The complexity isn’t worth it.

The other condition is that someone has to know how to maintain the Go service. If I am the only person who can rebuild it, the client is one Gus-gets-hit-by-a-bus event away from a problem. So when I ship a Go binary to a client, it comes with a small README, a systemd unit file, and a documented build process. The source lives in a repository the client can hand to a different developer if I am not available.

How they talk to each other

The Go service and WordPress don’t talk over HTTP, usually. They share a filesystem, or they share a database. PHP reads, Go writes, or vice versa.

Sharing the database is fast but couples the schemas. If you change a column in WordPress, the Go service breaks. I avoid this when I can. Sharing a separate SQLite file or a JSON file in a known location is slower but cleaner. WordPress reads a snapshot the Go service produces. The two never run queries against each other’s tables.

When the Go service needs to trigger WordPress (“a new submission arrived, please send the notification email”), I have it write to a queue file or call a single REST endpoint with a shared-secret header. WordPress polls the queue or responds to the endpoint, then does whatever PHP-side work needs to happen.

Why this matters for a small practice

For most small businesses, the answer to “should we add a Go service” is no. WordPress alone is enough. The reason I am writing this is that the question comes up, and when it does, the honest answer is “it depends on the workload.”

What I want to leave you with is the framing. Don’t reach for a second language because Go is fashionable or PHP is uncool. Reach for it when the workload genuinely doesn’t fit PHP’s strengths. The boring choice (a system cron and WP-CLI) is usually the right one. The interesting choice (a small, focused Go service) earns its place when the boring one keeps failing.

This connects to the hosting choices I wrote about earlier. A VPS that can run both WordPress and a Go binary doesn’t cost meaningfully more than one that only runs WordPress. The constraint isn’t the server. It is the human who has to keep both pieces alive.