PHP handles 40% of the web just fine - until it doesn’t. Bulk exports, heavy validation, CPU-bound work. That’s when “let’s add a small Python service” sounds obvious.
It’s real and deployable. But the tutorials stop at requests + WP REST API and skip the hard parts:
→ Trust boundary matters more than speed. Don’t hand your FastAPI service a WooCommerce ck_/cs_ key - that exposes your entire store. Use a bearer secret on a custom namespace, or HMAC-signed bodies (with server-side nonce storage, or it’s just
theatre).
→ Operations doubles. Two stacks = two deployments, two secrets, two on-calls.
→ The honest test: is the work bounded? File generation, bulk editors, Python-only ML libs - yes. “The admin would look nicer in Python” - no.
FastAPI + Pydantic is the right default. Keep the sidecar small, one responsibility, no second source of truth.
Lessons from production: <a href="https://stackcompass.dev/blog/wordpress-python-integration-tradeoffs/" target="_blank" rel="noopener nofollow">https://stackcompass.dev/blog/wordpress-python-integration-tradeoffs/</a>

If you want to discuss or share a link about any CMS, you're in the right place. Join us, we have cookies 🍪

Running a Python sidecar alongside WordPress seems like an obvious fix for CPU-bound tasks, bulk exports, or ML workloads that PHP handles poorly. However, the real trade-offs are rarely discussed in tutorials: trust boundaries require proper auth (bearer secrets or HMAC-signed bodies, not raw WooCommerce API keys), operational complexity doubles with two stacks to deploy and maintain, and the decision should hinge on whether the work is truly bounded. FastAPI + Pydantic is the recommended default, but the sidecar should stay small, single-responsibility, and never become a second source of truth.

WordPress + Python Sidecar: the trade-offs nobody tells you upfront